* Re: Release 1.4.2 build failure
From: Phillip Susi @ 2006-10-11 15:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejtfzur8.fsf@assigned-by-dhcp.cox.net>
Yes, I think the debian build system does that. I must have missed the
newer 1.4.2.x releases when scanning the directory. Thanks.
Junio C Hamano wrote:
> Are you by any chance running the test with the stdin connected
> to </dev/null?
>
> If so, the fix is in 1.4.2.2.
>
> BTW, the latest "maint" release is 1.4.2.3 and we have 1.4.3-rc2
> from the "master" branch.
>
^ permalink raw reply
* Re: core-git and porcelains
From: Shawn Pearce @ 2006-10-11 15:08 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <egivn8$5mf$1@sea.gmane.org>
Pazu <pazu@pazu.com.br> wrote:
> I'm a newcomer to git, and for the last few days, I've been struggling
> to learn how to better use git in my day to day. One particular thing
> that has been puzzling me is how much git is self-sufficient, and how
> much I should depend on porcelains.
>
> Apparently, I'm not alone in this:
> http://thread.gmane.org/gmane.comp.version-control.git/6194/focus=6194
>
> The above post was made about three months ago; where things stand now?
> Do you feel that git-core should suffice for most developers, or should
> I really look into something like Cogito?
>
> Depending on the project, my git usage would fit one of two profiles. I
> run some standalone projects, where I'm the sole developer. I was
> looking into using cogito for this scenario, but one thing that baffled
> me is how git-core and cogito use different branch representations.
>
> For the larger part of my day, however, I'm looking into using git as a
> personal tool in a very large corporate project; This project is
> currently controlled using subversion, and my idea is to use git as a
> 'staging' system, where I work (possibly offline) before pushing changes
> to the upstream (remote, slow as hell) subversion repository. Here,
> git-svn seems to be my best friend.
>
> Any advice to this poor newbie?
I would just stick with core Git. I haven't used Cogito in almost
a year so I can't say what I'm missing there, but core Git works
very well for all of my needs. I use it in a lot of different
projects, some which require git-svn, others which require some
bastard git-svn-workalike for non-SVN systems, and others which
are just Git projects and don't have to cooperate with others.
Git has come a long way in terms of user interface. It still has a
few rough edges but I think that there are less rough edges on core
Git's command line user interface than there are on the Subversion
command line client or the CVS command line client.
--
Shawn.
^ permalink raw reply
* core-git and porcelains
From: Pazu @ 2006-10-11 14:39 UTC (permalink / raw)
To: git
I'm a newcomer to git, and for the last few days, I've been struggling
to learn how to better use git in my day to day. One particular thing
that has been puzzling me is how much git is self-sufficient, and how
much I should depend on porcelains.
Apparently, I'm not alone in this:
http://thread.gmane.org/gmane.comp.version-control.git/6194/focus=6194
The above post was made about three months ago; where things stand now?
Do you feel that git-core should suffice for most developers, or should
I really look into something like Cogito?
Depending on the project, my git usage would fit one of two profiles. I
run some standalone projects, where I'm the sole developer. I was
looking into using cogito for this scenario, but one thing that baffled
me is how git-core and cogito use different branch representations.
For the larger part of my day, however, I'm looking into using git as a
personal tool in a very large corporate project; This project is
currently controlled using subversion, and my idea is to use git as a
'staging' system, where I work (possibly offline) before pushing changes
to the upstream (remote, slow as hell) subversion repository. Here,
git-svn seems to be my best friend.
Any advice to this poor newbie?
-- Marcus
^ permalink raw reply
* Re: [RFC] separate .git from working directory
From: Alex Riesen @ 2006-10-11 14:41 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0610110623q365d3ffcw9ba9e11936d03a9d@mail.gmail.com>
On 10/11/06, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Hi,
> I was thinking about this while reading subproject thread. In a simple
> case, I have a repo A located at ~/project-a and another repo B
> located at ~/project-a/some/dir/project-b. With this setup, command
> "find" and other directory-recursive commands will run horribly from
> ~/project-a when they go inside project-b/.git (no I don't want to
> repack -d everytime I want to find something).
> I propose to move project-b/.git outside and place a file, say
> .gitdir, in project-b directory. git-sh-setup and setup_git_directory
You can even leave the name as is: it is impossible to misunderstand
a file for directory (except on AIX). Or put the information in extended
attributes.
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Johannes Schindelin @ 2006-10-11 14:00 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <loom.20061011T140959-200@post.gmane.org>
Hi,
On Wed, 11 Oct 2006, Panagiotis Issaris wrote:
> Hi,
>
> Junio C Hamano <junkio <at> cox.net> writes:
> >[...]
> > And even for an isolated group where everybody knows that
> > everybody else runs DAV-enabled clients, they need info/refs
> > prepared for ls-remote and git-fetch script, which means you
> > will run update-server-info to keep objects/info/packs up to
> > date.
> This patch worked excellent for me. Thanks! :) Any chance this might
> make it into your tree?
It already is: adc446fe5d5f6dc1fb5edeaa9aa016ef94e70da1 from Sun Oct 8
12:56:19 2006 -0700 in branch 'next'.
Hth,
Dscho
^ permalink raw reply
* [RFC] separate .git from working directory
From: Nguyen Thai Ngoc Duy @ 2006-10-11 13:23 UTC (permalink / raw)
To: git
Hi,
I was thinking about this while reading subproject thread. In a simple
case, I have a repo A located at ~/project-a and another repo B
located at ~/project-a/some/dir/project-b. With this setup, command
"find" and other directory-recursive commands will run horribly from
~/project-a when they go inside project-b/.git (no I don't want to
repack -d everytime I want to find something).
I propose to move project-b/.git outside and place a file, say
.gitdir, in project-b directory. git-sh-setup and setup_git_directory
are taught to recognize .gitdir, read it to find the actual GIT_DIR
recorded inside .gitdir. This way git commands inside project-b should
work fine while I can "find ~/project-a -name blah" or "grep -R blah"
quickly.
.gitdir format could be a simple shell-like format with environment
variable assignments.
BTW, talking about subproject support, how about git be taught to
ignore directories which contain .gitdir so that git commands will not
waste time checking project-b directory?
--
Duy
^ permalink raw reply
* Re: Clueless bisect error message
From: Krzysztof Halasa @ 2006-10-11 12:51 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20061011091411.GA21527@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> + die "You can't bisect a seeked tree!"
Just to make sure: dictionary.reference.com doesn't know the
"seeked" word (I don't either though that may be normal).
Should it read "sought"? Not sure what does the message talk about.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Jakub Narebski @ 2006-10-11 12:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061010104149.GP20017@pasky.or.cz>
Petr "Pasky" Baudis wrote:
> Dear diary, on Tue, Oct 10, 2006 at 11:00:41AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
> > Petr Baudis wrote:
> >
> > > + print $_ while (<$fd>);
> >
> > Wouldn't it be better to do it in slurp mode, i.e.
> >
> > {
> > local $/
> > print <$fd>;
> > }
> >
> > instead?
>
> I personally prefer my version as it prevents allocation of big chunks
> of memory, but I don't really care in this particular case.
Can any Perl expert tell us how Perl truly solve this? What is the best
way to dump whole [remaining] contents of file (from filehandle) to STDOUT?
> > Do you assume that README is HTML fragment? If not, you should esc_html it.
> > Besides, we have similar (if assumed to have one line only) file, namely
> > description.
>
> I _do_ assume that README is HTML fragment (so that you can use links,
> non-proportional fonts, etc.), this is a difference to the description
> file.
Hmmm... perhaps better name would be description_long.html, or description.html
Or at least README.html.
Description could be moved to the config file; your's project README couldn't.
> > Besides, README for a project can be huge. Git README has 589 lines!
>
> This is not /README from the tree but README in the .git directory, so
> it may not be the same. In the repo.or.cz admin interface, I limit
> README to 8kb.
Sorry. My mistake.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH] Add WEBDAV timeout to http-fetch.
From: Panagiotis Issaris @ 2006-10-11 12:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vfydyinto.fsf@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano <junkio <at> cox.net> writes:
>[...]
> And even for an isolated group where everybody knows that
> everybody else runs DAV-enabled clients, they need info/refs
> prepared for ls-remote and git-fetch script, which means you
> will run update-server-info to keep objects/info/packs up to
> date.
This patch worked excellent for me. Thanks! :) Any chance this might make it
into your tree? I recommended GIT to the FFmpeg developers and would like to be
able to recommend them to use GIT without any extra patches.
> Nick, do you see holes in my logic?
With friendly regards,
Takis
^ permalink raw reply
* Re: [RFH] RPM gurus? (Re: rpmbuild fails)
From: Josef Weidendorfer @ 2006-10-11 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpscztg1c.fsf@assigned-by-dhcp.cox.net>
On Wednesday 11 October 2006 10:25, Junio C Hamano wrote:
> Does this look reasonable?
>
> -(find $RPM_BUILD_ROOT%{perl_vendorarch} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
> +(find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
That was exactly the modification I did, yes.
However, I can only say: It works for me (tm).
BTW, this is only Suse 10.1, x86.
Josef
^ permalink raw reply
* Re: gitweb: using quotemeta
From: Jakub Narebski @ 2006-10-11 9:48 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <20061007174121.44284.qmail@web31813.mail.mud.yahoo.com>
Luben Tuikov wrote:
> > Luben Tuikov used to_qtext in
> > "[PATCH] gitweb: Convert Content-Disposition filenames into qtext"
> > Msg-ID: <20061006191801.68649.qmail@web31815.mail.mud.yahoo.com>
> > http://permalink.gmane.org/gmane.comp.version-control.git/28437
>
> I think that people familiar with the RFC will be able to quickly
> recognize what this function does, after seeing "qtext" in the
> name of the function. After all, not only filenames can be qtext.
It wasn't meant to criticize. Just pointing out. It is nice
naming scheme (to_qtext, to_utf8) in addition to esc_* naming scheme.
I had no good idea for esc_* naming scheme for to_qtext subroutine...
so to_qtext is better.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-10-11 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wpfwg92.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> 1. Cleanups and refactoring
>>
>> * HTML and CSS cleanup. All (or almost all) styling should be done using
>> CSS, and not embedded style or presentation elements. All HTML elements
>> except perhaps a few should have either class attribute (if such
>> element can be multiple times on page) or id attribute (if there can be
>> only one such element). Perhaps some class attributes should be changed
>> to id attributes. Gitweb has much improved from the incorporation in
>> this area.
>
> It scares me when somebody says "all X should do Y". Aiming for
> consistency and cleanliness is good but taking it to extreme and
> becoming dogmatic about it isn't. Let's not repeat the crusade
> against redundant links.
Well, after writing this part I have checked that we don't use
"style" attribute in gitweb anymore. But we still do use presentational
elements, like <i>. IMHO we should use CSS for styling.
>> ... When the new
>> --grep/--author/--commiter options to git-rev-list hits released version,
>> perhaps also git_search could be put together with the previous set.
>
> Sounds like a good idea, but I think people can (and should)
> start preparing for it in "next"; after all that is what "next"
> is for.
Using --grep/--author/--commiter would have the advantage of to be
easily able to paginate "log search" in gitweb.
I forgot to add splitting git_search into "log search" and "pickaxe search",
and perhaps adding "file search" aka. "grep search" to gitweb.
>> * Refactor calling a git command and reading it's output into separate
>> subroutine git_command/git_pipe, so for example if someone _has_ to use
>> gitweb with ancient Perl version which does not understand list version
>> of magic "-|" open could do it changing only one subroutine. Well, we can
>> use Git.pm when it hits main release.
>
> I agree this is a good thing to do while refactoring. There are
> too many similar looking code sprinkled all over. Git.pm is
> already in the "master" and there is nothing cooking in "next".
I'm not sure if I would like to use Git.pm repository abstraction.
But converting gitweb to use Git.pm would be a good idea, I agree.
Although I'd rather have any gitweb patches which need _unreleased_
features to be in 'next'.
BTW. the Git.pm-ish ideas (config parser, remotes parser, symrefs and
packed refs parser) should perhaps be added (at least in 'next')
via Git.pm.
>> * Add simplified git config file parser, which would _read_ only gitweb
>> entries (and convert them to bool/int if necessary). With this we could
>> move description, category, export_ok, .hide, cloneurl to config file,
>> instead of cluttering $GIT_DIR. Or just make it an option (read file
>> first, if it doesn't exist try config file).
>
> I do not see why you would need anything "simplified"; I think
> writing a .git/config parser purely in Perl is much easier than
> waiting for libified interface that talks .xs and would run just
> as efficient -- after all Perl is the ideal tool for text file
> processing like this. And I do not particularly worry about
> issues that could arise from two different configuration parsers
> having different set of bugs. The file format is simple enough.
> It would be a very good addition to Git.pm suite.
There are many INI file parsers in CPAN, but I guess that Git adds
it's own config file syntax (e.g. branch and remote config:
[branch "quoted branch name with funny characters]
which is not yet documented if I remember correctly) that we want our
own parser; this would also reduce dependencies.
"Simplified" because of not implementing "extended syntax" mentioned
above, and because implementing only reading config file. It is harder
to make it write config file, preserving comments etc.
By the way, would it be better to use CGI like syntax of
$repo->config("gitweb.$key"), or tie hash?
>> * Code highlighting (or generic filter) support in blob view, perhaps as
>> a feature.
>
> Not particularly interested myself but as long as it would not
> add huge load on the server I would not much object either.
It should be: as a feature, not perhaps as a feature. Perhaps
make highlighting configurable (program to use, filename to mode
mapping, etc.)
>> * Crossreferencing in blob view.
>
> LXR is certainly interesting, but I would rather use local "git grep".
This is far, far in the queue at least for me. And I'm not sure
if crossreferencing can be done without creating temporary files,
something we tried to avoid (e.g. creating diffs on-the-fly now).
>> * add summary of number of lines changed for each file (a la darcsview)
>> in the difftree part of commit and *diff* views, e.g.
>>
>> blame.c +1 -0 diff | history | blame
>>
>> or something like that.
>
> I'll place "diff --numstat" to the stack of "things to do on the
> core side". Should be trivial.
Thanks. I did wonder why git-apply (!) has "--numstat" but git-diff
has not...
>> * "List of the files in given directory, touched by given commit"
>
> Have no idea what you mean. "diff-tree -r --name-only $commit"?
I'm repeating verbatim someone idea. IIRC it meant adding list
of affected files (like difftre part of "commit" and "commitdiff"
views) to the "log" and "search" views...
>> X. Proposed improvements to core git commands
>> * add --stdin option to git-ls-tree, a la --stdin option to git-diff-tree.
>
> Not particularly interested, as it is unclear how the output
> boundary should be marked, but should be trivial to add once we
> know what the output should look like.
The output format for git-ls-tree is
<mode> SP <type> SP <object> TAB <file>
It is fairly easy to distinguish such line from the
<sha1 of tree-ish>
line.
The idea was that
echo "tree-ish 1" "tree-ish 2" | git ls-tree --stdin
output would be
<sha1 of tree-ish 1>
<mode> SP <type> SP <object> TAB <file>
...
<mode> SP <type> SP <object> TAB <file>
<sha1 of tree-ish 2>
<mode> SP <type> SP <object> TAB <file>
...
<mode> SP <type> SP <object> TAB <file>
We could add some records (trees) seperating, for example by NUL
character like in git-rev-list --headers.
>> * add --follow option to git-rev-list, allow to provide path limiter via
>> stdin (with --stdin option) in git-diff-tree
>
> The "path limiter via stdin" part is murky. I would not object
> to "rev-list --follow=$this_path_at_the_tip $start_at_this_commit"
> which I can see clear semantics for.
You can provide <tree-ish> or pair of <tree-ish> from stdin for
git-diff-tree --stdin. You can provide path limiter _only_ as an
argument to git-diff-tree. Proposed extension is to be able to
use
<tree-ish> [<tree-ish>] [<path>...]
from stdin, perhaps _forcing_ to use
<tree-ish> [<tree-ish>] ['--' <path>...]
syntax.
Alternatively, change semantics of path limiter if path limiter
match _exactly_ --follow argument.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Clueless bisect error message
From: Jeff King @ 2006-10-11 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v1wpfuv9d.fsf@assigned-by-dhcp.cox.net>
On Wed, Oct 11, 2006 at 01:11:42AM -0700, Junio C Hamano wrote:
> But I suspect that doing either of these things would harm
> Cogito users. After cg-seek the user is not "in the middle of
> another bisect", and if we run "git bisect --reset" when we see
> head-name, it would probably break it too.
Maybe expand head-name to include a "reason" field? Unfortunately we
can't just stick it in the same file and remain compatible with all
versions, so we'll have to use a new file. Something like:
-- >8 --
git-bisect: use head-reason to explain use of head-name
Since many different programs may use head-name to indicate that the working
tree should not be modified, head-reason gives them a chance to explain what
they're doing. This can improve the accuracy of error messages (such as won't
bisect a seeked tree).
Signed-off-by: Jeff King <peff@peff.net>
---
Alternatively, the actual message to show the user could be placed in
head-reason. I think it makes more sense as it is, as it provides the
ability for the message to say "can't X because of Y" in plain English.
And of course we need cogito to start supporting this (but we print
something sane for older versions with don't support head-reason).
git-bisect.sh | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 06a8d26..9f49dd3 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -57,8 +57,21 @@ bisect_start() {
git checkout $branch || exit
;;
refs/heads/*)
- [ -s "$GIT_DIR/head-name" ] && die "won't bisect on seeked tree"
+ if [ -s "$GIT_DIR/head-name" ]; then
+ case "$(cat "$GIT_DIR/head-reason" 2>/dev/null)" in
+ bisect)
+ die "You are already in the middle of another bisect!"
+ ;;
+ seek)
+ die "You can't bisect a seeked tree!"
+ ;;
+ *)
+ die "head-name already exists"
+ ;;
+ esac
+ fi
echo "$head" | sed 's#^refs/heads/##' >"$GIT_DIR/head-name"
+ echo bisect >"$GIT_DIR/head-reason"
;;
*)
die "Bad HEAD - strange symbolic ref"
@@ -182,6 +195,7 @@ bisect_reset() {
git checkout "$branch" &&
rm -fr "$GIT_DIR/refs/bisect"
rm -f "$GIT_DIR/refs/heads/bisect" "$GIT_DIR/head-name"
+ rm -f "$GIT_DIR/head-reason"
rm -f "$GIT_DIR/BISECT_LOG"
rm -f "$GIT_DIR/BISECT_NAMES"
}
--
1.4.2.3.g2c59-dirty
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] gitweb: blame porcelain: lineno and orig lineno swapped
From: Junio C Hamano @ 2006-10-11 8:37 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20061011073005.1178.qmail@web31813.mail.mud.yahoo.com>
Sheesh. I thought I swapped both blame side and gitweb side to
match your suggestion but apparently I didn't.
Thanks for catching this.
^ permalink raw reply
* Re: Clueless bisect error message
From: Nguyen Thai Ngoc Duy @ 2006-10-11 8:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wpfuv9d.fsf@assigned-by-dhcp.cox.net>
On 10/11/06, Junio C Hamano <junkio@cox.net> wrote:
> My point actually was that even a simple rewording is harder
> than it seems, because that cluelessness actually was introduced
> to help Cogito. If we do not care about it, we can just reword
> it to say "Hey you are in the middle of another bisect, or maybe
> you left your bisect by doing git-checkout earlier? In either
> case git-bisect --reset is your friend, oh, and we can run that
> for you now if you want". We could even remove head-name in
> git-checkout when we see one.
>
> But I suspect that doing either of these things would harm
> Cogito users. After cg-seek the user is not "in the middle of
> another bisect", and if we run "git bisect --reset" when we see
> head-name, it would probably break it too.
Thanks. Now I understand the issue. I'm sorry for my ignorant because
I haven't used cogito yet.
--
Duy
^ permalink raw reply
* Re: [RFH] RPM gurus? (Re: rpmbuild fails)
From: Junio C Hamano @ 2006-10-11 8:25 UTC (permalink / raw)
To: git
In-Reply-To: <7v64erznyj.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
>> Obviously, the generated perl/Makefile installs Git.pm
>> into the perl vendor *library* directory, and not the arch
>> one.
Does this look reasonable?
-- >8 --
git.spec.in: perl subpackage is installed in perl_vendorlib not vendorarch
Signed-off-by: Junio C Hamano <junio@hera.kernel.org>
---
git.spec.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index 6d90034..9b1217a 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -97,7 +97,7 @@ find $RPM_BUILD_ROOT -type f -name '*.bs
find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
-(find $RPM_BUILD_ROOT%{perl_vendorarch} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
+(find $RPM_BUILD_ROOT%{perl_vendorlib} -type f | sed -e s@^$RPM_BUILD_ROOT@@) >> perl-files
%if %{!?_without_docs:1}0
(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email|gitk" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%else
--
1.4.3.rc2.gcc59
^ permalink raw reply related
* Re: [PATCH] cvsserver: fix "cvs diff" in a subdirectory
From: Johannes Schindelin @ 2006-10-11 8:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martyn Smith, Martin Langhoff
In-Reply-To: <7vslhvy8bo.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 10 Oct 2006, Junio C Hamano wrote:
> Will park this and the "U for update, M for modified" patch in
> "pu", waiting for acks from actual git-cvsserver users. It
> feels it is safe enough change, so with an Ack from Mart[yi]n
> it may be woth having it in 1.4.3
Thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: Clueless bisect error message
From: Junio C Hamano @ 2006-10-11 8:11 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0610110050h4c3a56fbge19607ff0bc094af@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>> By looking at commit 810255f, however, I suspect that fix would
>> break Cogito. The wording of the message actually comes from
>> Cogito nomenclature.
> Ah. I forgot to say I'm using git 1.4.2.1. My only wish is not a fix
> (unless it's a trivial fix) but that bisect should explain the
> situation better and guide people to fix it. I had grepped bisect man
> page for "seeked tree" and was still clueless.
My point actually was that even a simple rewording is harder
than it seems, because that cluelessness actually was introduced
to help Cogito. If we do not care about it, we can just reword
it to say "Hey you are in the middle of another bisect, or maybe
you left your bisect by doing git-checkout earlier? In either
case git-bisect --reset is your friend, oh, and we can run that
for you now if you want". We could even remove head-name in
git-checkout when we see one.
But I suspect that doing either of these things would harm
Cogito users. After cg-seek the user is not "in the middle of
another bisect", and if we run "git bisect --reset" when we see
head-name, it would probably break it too.
^ permalink raw reply
* Re: Approxidate licensing
From: David Woodhouse @ 2006-10-11 7:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610101246241.9789@iabervon.org>
On Tue, 2006-10-10 at 13:39 -0400, Daniel Barkalow wrote:
> Would the three of you agree to license date.c under the LGPL or BSD? It
> looks like you're the only authors of non-trivial changes [1]. And it seems
> reasonable to want the date parsing thing under non-GPL terms outside of
> git.
Yeah, LGPL and BSD are both fine by me -- although I don't actually
recognise much of my own code in there.
Btw, why isn't the meaning of 'tea-time' properly modified according to
the locale?
--
dwmw2
^ permalink raw reply
* Re: Approxidate licensing
From: Junio C Hamano @ 2006-10-11 7:55 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, dwmw2, git
In-Reply-To: <Pine.LNX.4.64.0610101246241.9789@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> [1] git log and git blame are pretty impressive, but they don't quite
> catch that most of date.c was written by David as part of commit-tree.c,
> then Tony replaced it with a version that uses curl, then Edgar separated
> it out into a date.c and simultaneously reverted Tony's changes. On the
> other hand, the commit messages do say this, and you can use git log and
> git blame to verify that they're true. The only thing they don't let
> you verify is what the differences are between the date.c added in
> ecee9d9e and the similar part of commit-tree.c in 812666c8. If someone
> wants to make git blame *really* magic, date.c would be a good test case.
That's good to know. I have in my head a super-duper blame that
I outlined in my obituary for git-annotate, but that is still a
vaporware and will continue to be for some time.
^ permalink raw reply
* Re: Clueless bisect error message
From: Nguyen Thai Ngoc Duy @ 2006-10-11 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsczuxj9.fsf@assigned-by-dhcp.cox.net>
On 10/11/06, Junio C Hamano <junkio@cox.net> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > $ git bisect start
> > won't bisect on seeked tree
> >
> > It complained because .git/head-name contained 't' which had been
> > deleted before. git-bisect reset works. However I'd request git-bisect
> > to inform more useful messages. At first, I was completely stunned:
> > "what is a seeked tree? how can I fix that?"
>
> Interesting. There is certainly something clueless but I am not
> sure if it is git-bisect.
>
> Other git-core tools never create $GIT_DIR/head-name unless
> bisect is in effect, and you end your bisect session by doing
> "bisect reset" (otherwise there is no easy way to get back to
> your original branch head). How did head-name got 't' in it,
> and how was branch 't' removed?
Well, I probably removed it myself. It's one of my temporary branches
IIRC. Perhaps I forgot to do "bisect reset".
>
> If the answer to the first question is because earlier you
> created a temporary branch 't' to run a bisect, and the answer
> to the latter is because you ended your bisect session by saying
> "git checkout -f someotherbranch && git branch -D t", then we
> should be able to fix that by removing head-name upon branch
> switching with "git checkout".
That might be the case. I used bisect on this repo a long ago. I'm not
sure what actually happened.
>
> By looking at commit 810255f, however, I suspect that fix would
> break Cogito. The wording of the message actually comes from
> Cogito nomenclature.
Ah. I forgot to say I'm using git 1.4.2.1. My only wish is not a fix
(unless it's a trivial fix) but that bisect should explain the
situation better and guide people to fix it. I had grepped bisect man
page for "seeked tree" and was still clueless.
--
Duy
^ permalink raw reply
* [PATCH] gitweb: blame porcelain: lineno and orig lineno swapped
From: Luben Tuikov @ 2006-10-11 7:30 UTC (permalink / raw)
To: git
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 77063f0..19f434d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2594,7 +2594,7 @@ HTML
while (1) {
$_ = <$fd>;
last unless defined $_;
- my ($full_rev, $lineno, $orig_lineno, $group_size) =
+ my ($full_rev, $orig_lineno, $lineno, $group_size) =
/^([0-9a-f]{40}) (\d+) (\d+)(?: (\d+))?$/;
if (!exists $metainfo{$full_rev}) {
$metainfo{$full_rev} = {};
--
1.4.3.rc2.gacda
^ permalink raw reply related
* Re: Clueless bisect error message
From: Junio C Hamano @ 2006-10-11 7:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0610110008g642da719pb17f7f52169097e2@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> $ git bisect start
> won't bisect on seeked tree
>
> It complained because .git/head-name contained 't' which had been
> deleted before. git-bisect reset works. However I'd request git-bisect
> to inform more useful messages. At first, I was completely stunned:
> "what is a seeked tree? how can I fix that?"
Interesting. There is certainly something clueless but I am not
sure if it is git-bisect.
Other git-core tools never create $GIT_DIR/head-name unless
bisect is in effect, and you end your bisect session by doing
"bisect reset" (otherwise there is no easy way to get back to
your original branch head). How did head-name got 't' in it,
and how was branch 't' removed?
If the answer to the first question is because earlier you
created a temporary branch 't' to run a bisect, and the answer
to the latter is because you ended your bisect session by saying
"git checkout -f someotherbranch && git branch -D t", then we
should be able to fix that by removing head-name upon branch
switching with "git checkout".
By looking at commit 810255f, however, I suspect that fix would
break Cogito. The wording of the message actually comes from
Cogito nomenclature.
^ permalink raw reply
* Re: [PATCH] gitweb: Fix zebra coloring flip introduced by eeef88cd2
From: Luben Tuikov @ 2006-10-11 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk637xxxr.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> I do not have much preference either way, but it was done more
> or less deliberately to match what you did with 6dd36ac.
Sorry, I didn't mean to introduce the apparent inconsisteny.
The 6dd36ac touches alternate "active" shading, and blame
only shows the contents, albeit with the commit-8 and block
coloring.
Luben
^ permalink raw reply
* Clueless bisect error message
From: Nguyen Thai Ngoc Duy @ 2006-10-11 7:08 UTC (permalink / raw)
To: git
$ git bisect start
won't bisect on seeked tree
It complained because .git/head-name contained 't' which had been
deleted before. git-bisect reset works. However I'd request git-bisect
to inform more useful messages. At first, I was completely stunned:
"what is a seeked tree? how can I fix that?"
--
Duy
^ 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