* Re: On removing files and "git-rm is pointless"
From: Junio C Hamano @ 2006-12-04 10:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds, Carl Worth, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0612022246310.2630@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I think what Linus is proposing makes tons of sense.
>
> If you do git rm by mistake then you can always do git checkout on that
> file to get it back.
>
> If you modified it so it doesn't match the index then git rm won't do
> anything by default so you have a chance to think a bit more.
>
> If you updated the index, didn't commit anything but then do git rm then
> you certainly wanted to really rm the file.
FWIW, I too am in favor of the proposed fix to "git rm" as Linus
outlined.
^ permalink raw reply
* Re: [PATCH 1/2] move Git.pm build instructions into perl/Makefile
From: Junio C Hamano @ 2006-12-04 10:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612040156w794a276cqaa37f1734ba7a1ca@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> Updated patch attached.
Will apply, thanks, but with a few tweaks while I had to hand
munge your attachment anyway.
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Jakub Narebski @ 2006-12-04 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virgstmg6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> The subroutine should return either reference to scalar which means
>> "do not process", scalar which means changed available for further
>> processing, or void (undef) which means no change. In [PATCH 2/3] we
>> will enable returning also list of elements, each of which could be
>> reference to scalar or scalar (for example signoff would return three
>> element list: opening span element as ref, signoff text as scalar,
>> closing span element as ref).
>
> Personally I think that "list of elements" should be in the
> first patch to build the foundation.
O.K. (By the way, that is why I posted this RFC without sending patch.)
Especially that in this version this is easy and there are no reasons
against it (in previous version %committag entries had 'islink' field,
and returned value was "wrapped" in format_log_line_html in
</a>...<a ...>; I think I'll chose pre-output wrapping <a> elements).
>> our %committags = (
>> 'sha1' => {
>> 'pattern' => qr/[0-9a-fA-F]{40}/,
>> 'sub' => sub {
>> my $hash_text = shift;
>> my $type = git_get_type($hash_text);
>> if ($type) {
>> return \$cgi->a({-href => href(action=>$type, hash=>$hash_text),
>> -class => "text"}, $hash_text);
>> }
>> return undef;
>> },
>> },
>
> It might make sense to do a /[0-9a-f]{8,40}/ pattern, and make
> sure that the named object exists in the sub (which you already
> do). People often write abbreviated commit object name that has
> a high chance of staying unique during the life of the project.
That's right. I'll do it. By the way, it might make sense to add
qr/\bv[0-9]+(\.[0-9]+){1,3}(-[a-z]+[0-9]+)\b/ to match "version" tags.
I have one gripe about "git-cat-file -t". I'd like it to have
-q/--quiet, -s/--silent, --hush (or --dont-spew-errors-on-stdout)
which would prohibit writing "object not found" errors on stderr
(and in gitweb case to webserver logs). I know I can use "git-cat-file -e"
to check if object exists, or modify git_get_type subroutine
# get type of given object
sub git_get_type {
my $hash = shift;
my $git_command = git_cmd_str();
open my $fd, "-|",
"$git_command cat-file -t $hash 2>/dev/null"
or return '';
my $type = <$fd>;
close $fd
or return '';
chomp $type;
return $type;
}
but both those solutions means one fork more.
>> 'mantis' => {
>> 'pattern' => qr/(BUG|FEATURE)\(\d+\)/,
>> 'bugzilla' => {
>> 'pattern' => qr/bug\s+\d+/,
>
> This is not wrong per-se but somehow feels funny. It feels as
> if there is a convention that bugzilla bugs are usually spelled
> in lowercase while mantis bugs are in uppercase, but I do not
> think you are suggesting that.
The Mantis pattern is taken from committags support in gitweb-xmms2,
http://git.xmms.se/?p=gitweb-xmms2.git while Bugzilla pattern is
taken from Mozilla Bugzilla entries.
> I do not know how this %committags{} is used per project. With
> a setting like repo.or.cz, it is likely that one instance of
> gitweb is serving unrelated projects that have their issue
> tracker at different locations using different "committags"
> convention. Is the idea to eventually allow enabling/disabling
> elements from the global %committags per repository somehow
> (perhaps not just enable/disable but even overriding patterns or
> parameters)?
I have thought about putting %committags and @committags before
loading config file
do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
which can load config file depending on the project, but perhaps
it is too complicated solution.
Another solution would be to add 'committags' feature, which would
control at least some of the configurable elements of %committags
and @committags (of committags support). At minimum control which
committags are turned on, and in what sequence.
>> 3. To not split message into many fragments we concatenate strings
>> if possible.
>
> I do not know why "avoiding splits" is needed, if it raises
> issues that you need to ask the list about in a message like
> this...
"Avoiding splits" is needed first for performance, and second to
avoid situation where pattern would match on the boundary between
two strings in a list of tokens to process.
The improved version of push_or_append follows:
sub push_or_append (\@@) {
my $list = shift;
if (ref $_[0] || ref $list->[-1] || ! @$list) {
return push @$list, @_;
} else {
my $a = pop @$list;
my $b = shift @_;
return push @$list, $a . $b, @_;
}
}
Or the variant which I wouldn't use ;-P (well, at least not in the
form below).
sub push_or_append (\@@) {
my $aref = shift;
my @list = @_;
try {
return push @$aref[0..$#$aref-1],
$aref->[-1] . $list[0],
@list[1..$#list]
} catch {
return push @$aref, @list;
}
}
--
Jakub Narebski
^ permalink raw reply
* Re: Some advanced index playing
From: Junio C Hamano @ 2006-12-04 10:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alan Chandler, git
In-Reply-To: <Pine.LNX.4.64.0612031008360.3476@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think that is actually a misfeature.
>
> This _should_ just work. It's the easy and logical way to do it, and it's
> the one that matches all the other behaviours of "git commit" these days.
> ...
> So anyway, I would suggest that we just get rid of that partial commit
> "safety check" in "git commit" for now. It still makes sense for when
> you're in the middle of a _merge_, but the "verify that index matches" is
> not worth it.
The codepath has a big "don't do this during a merge" check in
front. I think this is a safe thing to do, so let's do this.
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..c829791 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -350,19 +350,9 @@ t,)
refuse_partial "Cannot do a partial commit during a merge."
fi
TMP_INDEX="$GIT_DIR/tmp-index$$"
- if test -z "$initial_commit"
- then
- # make sure index is clean at the specified paths, or
- # they are additions.
- dirty_in_index=`git-diff-index --cached --name-status \
- --diff-filter=DMTU HEAD -- "$@"`
- test -z "$dirty_in_index" ||
- refuse_partial "Different in index and the last commit:
-$dirty_in_index"
- fi
commit_only=`git-ls-files --error-unmatch -- "$@"` || exit
- # Build the temporary index and update the real index
+ # Build a temporary index and update the real index
# the same way.
if test -z "$initial_commit"
then
^ permalink raw reply related
* Re: On removing files and "git-rm is pointless"
From: Jakub Narebski @ 2006-12-04 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vd570q888.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
>> I think what Linus is proposing makes tons of sense.
>>
>> If you do git rm by mistake then you can always do git checkout on that
>> file to get it back.
>>
>> If you modified it so it doesn't match the index then git rm won't do
>> anything by default so you have a chance to think a bit more.
>>
>> If you updated the index, didn't commit anything but then do git rm then
>> you certainly wanted to really rm the file.
>
> FWIW, I too am in favor of the proposed fix to "git rm" as Linus
> outlined.
+1. I'm also for this change. Of course if the working area version doesn't
match HEAD version git-rm should remove only index entry, and print warning
message, for example what it does now, i.e.
rm '<filename>'
or if we want more chatty version (core.gitgor = true) it would print:
File '<filename>' changed. Use "rm '<filename>'" to remove.
(or something like that).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Johannes Schindelin @ 2006-12-04 10:52 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Junio C Hamano, git
In-Reply-To: <505428.75434.qm@web31808.mail.mud.yahoo.com>
Hi,
On Sun, 3 Dec 2006, Luben Tuikov wrote:
> This patch merely allows the user to say
> git-checkout-index --stage=ours their_broken_file.c
> instead of
> git-checkout-index --stage=2 their_broken_file.c
> and similarly for "theirs", etc.
Dunno. When this problem hits me, I usually do
git diff --theirs their_broken_file.c
anyway, to see what it is doing (colour and all). When I am satisfied,
that "theirs" is really what I want, I just go back one in history, and
append a call to git-apply like this:
git diff --theirs their_broken_file.c | git apply --index
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Junio C Hamano @ 2006-12-04 10:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612041133.44816.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I have one gripe about "git-cat-file -t". I'd like it to have
> -q/--quiet, -s/--silent, --hush (or --dont-spew-errors-on-stdout)
> which would prohibit writing "object not found" errors on stderr
> (and in gitweb case to webserver logs). I know I can use "git-cat-file -e"
> to check if object exists, or modify git_get_type subroutine
>
> # get type of given object
> sub git_get_type {
> my $hash = shift;
> my $git_command = git_cmd_str();
>
> open my $fd, "-|",
> "$git_command cat-file -t $hash 2>/dev/null"
> or return '';
It is one thing if you tend to randomly throw garbage at this
function and use it to check for object's existence, but I hope
you are already checking the user input (which is what $hash is,
I think, here), and the object is supposed to exist in the
repository you are looking at. In such a case, I think you and
your server administrator have right to know about that
situation; I do not see why you would want to squelch it.
>> I do not know how this %committags{} is used per project. With
>> a setting like repo.or.cz, it is likely that one instance of
>> gitweb is serving unrelated projects that have their issue
>> tracker at different locations using different "committags"
>> convention. Is the idea to eventually allow enabling/disabling
>> elements from the global %committags per repository somehow
>> (perhaps not just enable/disable but even overriding patterns or
>> parameters)?
>
> I have thought about putting %committags and @committags before
> loading config file
> do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
> which can load config file depending on the project, but perhaps
> it is too complicated solution.
I think you are talking about a gitweb-instance wide
customization, but that's not what I meant. I meant per-project
configuration where w/git-gui.git and w/git.git are served by
the same instance of gitweb but have pointers to different issue
trackers.
>>> 3. To not split message into many fragments we concatenate strings
>>> if possible.
>>
>> I do not know why "avoiding splits" is needed, if it raises
>> issues that you need to ask the list about in a message like
>> this...
>
> "Avoiding splits" is needed first for performance, and second to
> avoid situation where pattern would match on the boundary between
> two strings in a list of tokens to process.
I wouldn't know if constantly splitting and then concatenating
is faster than just concatenatting once before output without
benchmarking, so I'd refrain from talking about performance.
Two string case may be a valid concern, though.
^ permalink raw reply
* Re: [DRAFT 2] Branching and merging with git
From: Johannes Schindelin @ 2006-12-04 10:56 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux, git
In-Reply-To: <20061204072350.GC28043@fieldses.org>
Hi,
On Mon, 4 Dec 2006, J. Bruce Fields wrote:
> So I'm trying to split out an extremely concise "quick-start" guide
> (modelled partly on Mercurial's) that doesn't even pretend to explain
> anything,
you might want to look at the QuickStart page in Git's wiki...
> 1. clone
> 2. checking out old versions, basic branch management
> 3. keeping up-to-date with fetch
> 4. bisect
> 5. archaeology (commits DAG, git-log, ...)
> 6. creating commits, index file
> 7. resolving merges, pull
> 8. publishing a public repository, push
Another approach would be to illustrate short stories of a failed merge,
or "how I put up a public repository", etc. Like, more example-based (and
of course short enough that people actually read through it).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-04 11:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: skimo, sf, git, Martin Waitz, sf, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612031421030.3476@woody.osdl.org>
On Sunday 03 December 2006 23:32, Linus Torvalds wrote:
> So a particular instance of a submodule might be "aware" of the fact that
> it's a submodule of a supermodule. For example, the "awareness" migth be
> as simple as just a magic flag file inside it's .git/ directory. And that
> awareness would be what simply disabled pruning or "repack -d" within that
> particular instance.
That prohibits the problem in your supermodule and your instance of the
given submodule.
But IMHO, using a submodule commit which could be removed by pruning in
another instance of the submodule is really not the thing you ever want.
If you start your own branch in a submodule, and start to rely on it in
the supermodule, you _will_ want to push this to the submodule upstream.
And if you find that you have to rebase in the submodule, you simply
have to rewrite your branch commits in the supermodule too. Otherwise,
you effectively fork the submodule project purely for your superproject.
So I suppose that in practical use, pruning in submodules probably
would not have any negative effect. If it has, you made something
wrong. So you probably should only a submodule commit if it has
"publishing quality" (unless being on a temporary supermodule branch).
Ie. any "borrowers" file should be empty.
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Jakub Narebski @ 2006-12-04 11:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz64ortu.fsf@assigned-by-dhcp.cox.net>
Dnia poniedziałek 4. grudnia 2006 11:53, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I have one gripe about "git-cat-file -t". I'd like it to have
>> -q/--quiet, -s/--silent, --hush (or --dont-spew-errors-on-stdout)
>> which would prohibit writing "object not found" errors on stderr
>> (and in gitweb case to webserver logs). I know I can use
>> "git-cat-file -e" to check if object exists, or modify git_get_type
>> subroutine
>>
>> # get type of given object
>> sub git_get_type {
>> my $hash = shift;
>> my $git_command = git_cmd_str();
>>
>> open my $fd, "-|",
>> "$git_command cat-file -t $hash 2>/dev/null"
>> or return '';
>
> It is one thing if you tend to randomly throw garbage at this
> function and use it to check for object's existence, but I hope
> you are already checking the user input (which is what $hash is,
> I think, here), and the object is supposed to exist in the
> repository you are looking at. In such a case, I think you and
> your server administrator have right to know about that
> situation; I do not see why you would want to squelch it.
I'm sorry, I should mention that this "quiet" mode of operation is
needed _only_ for committags support, for example by using
git_get_type($hash_text, -quiet=>1) in 'sha1' committag subroutine.
You might have sha1 ids in commit message which no longer point to valid
(existing) object, for example commit which is result of
"git cherry-pick -x" from no longer existing temporary branch, or commit
which is result of "git revert" on a branch which got rebased (but not
reorganized), or shortened sha1 which is no longer unique. This should
not cause errors to be written to webserver log.
By the way, is it better to use anonymous subroutines for committags
subs, or use explicit subroutines?
>>> I do not know how this %committags{} is used per project. With
>>> a setting like repo.or.cz, it is likely that one instance of
>>> gitweb is serving unrelated projects that have their issue
>>> tracker at different locations using different "committags"
>>> convention. Is the idea to eventually allow enabling/disabling
>>> elements from the global %committags per repository somehow
>>> (perhaps not just enable/disable but even overriding patterns or
>>> parameters)?
>>
>> I have thought about putting %committags and @committags before
>> loading config file
>> do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
>> which can load config file depending on the project, but perhaps
>> it is too complicated solution.
>
> I think you are talking about a gitweb-instance wide
> customization, but that's not what I meant. I meant per-project
> configuration where w/git-gui.git and w/git.git are served by
> the same instance of gitweb but have pointers to different issue
> trackers.
You can always use $ENV{PATH_INFO} in $GITWEB_CONFIG value,
or check out path_info and/or $cgi->params('p') in the config file.
Or perhaps other way to set-up per repository config file.
But this is a bit complicated to set up.
I don't have definite answer about how configure committags
(both the committags enabled and sequence of committags, and
committags parameters) per repository. We can use gitweb.committags
config variable for committags enables/sequence, but how configure
committags? gitweb.committag.<name>?
BTW in some cases (e.g. xmms2 projects) issue tracker is common for
all projects hosted.
>>>> 3. To not split message into many fragments we concatenate strings
>>>> if possible.
>>>
>>> I do not know why "avoiding splits" is needed, if it raises
>>> issues that you need to ask the list about in a message like
>>> this...
>>
>> "Avoiding splits" is needed first for performance, and second to
>> avoid situation where pattern would match on the boundary between
>> two strings in a list of tokens to process.
>
> I wouldn't know if constantly splitting and then concatenating
> is faster than just concatenatting once before output without
> benchmarking, so I'd refrain from talking about performance.
> Two string case may be a valid concern, though.
With current implementation it is very easy to switch this one and off.
You simply either use push, or push_or_append (or make push_or_append
do just push).
Previous (not published) version used $acc variable to concatenate
strings, but I think this solution is better (and simpler).
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Jakub Narebski @ 2006-12-04 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612041149410.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sun, 3 Dec 2006, Luben Tuikov wrote:
>
>> This patch merely allows the user to say
>> git-checkout-index --stage=ours their_broken_file.c
>> instead of
>> git-checkout-index --stage=2 their_broken_file.c
>> and similarly for "theirs", etc.
>
> Dunno. When this problem hits me, I usually do
>
> git diff --theirs their_broken_file.c
>
> anyway, to see what it is doing (colour and all). When I am satisfied,
> that "theirs" is really what I want, I just go back one in history, and
> append a call to git-apply like this:
>
> git diff --theirs their_broken_file.c | git apply --index
Then
git checkout --theirs their_broken_file.c
is obvious simplification.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: problem in unpack-trees.c
From: Roman Zippel @ 2006-12-04 11:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodqkq956.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 4 Dec 2006, Junio C Hamano wrote:
> Roman Zippel <zippel@linux-m68k.org> writes:
>
> > I looked into it and the problem is during the "git-read-tree --reset"
> > step and it seems that the local df_conflict_entry variable of
> > unpack_trees() survives past that function. If you check in
> > add_cache_entry() it's called with this variable and only because
> > verify_path() fails it's not added to the tree on the other archs, but on
> > m68k the data on the stack is a bit different and thus verify_path()
> > succeeds and the stack variable is added to the tree and later saved.
>
> I am very puzzled about this.
>
> You are correct that the address of the df_conflict_entry is
> assigned to "struct unpack_trees_options *o" in unpack_trees(),
> and add_cache_entry() are called from many places in the call
> chain that starts from that function. And these call sites do
> rely on the conflict_entry to have a NUL name to prevent
> add_cache_entry from adding the entry to the index. Which feels
> like a hack, but it should get the job done while it is running.
Ok, I see, I wasn't sure that this part was really intentional.
> On my x86-64 box with gcc 4 (i.e. "#define FLEX_ARRAY /* empty */"
> is used,
>
> #include "cache.h"
>
> int
> main(int ac, char **av)
> {
> printf("sz %zu\n", sizeof(struct cache_entry));
> printf("of %zu\n", offsetof(struct cache_entry, name));
> memset(&dfc, 0, sizeof(dfc));
> }
>
> size of "struct cache_entry" is 64 while the offset of name
> member is 62, so I am luckily getting two bytes of room for
> memset to fill and cause name[] to be properly NUL terminated.
> If the alignment requirement of the platform is smaller, we may
> be overstepping the struct when we access its name[] member.
Yes, on m68k both values are the same and thus name is not initialized.
Your patch should do the trick, I'll give it a try.
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Johannes Schindelin @ 2006-12-04 11:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el113s$25v$1@sea.gmane.org>
Hi,
On Mon, 4 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > On Sun, 3 Dec 2006, Luben Tuikov wrote:
> >
> >> This patch merely allows the user to say
> >> git-checkout-index --stage=ours their_broken_file.c
> >> instead of
> >> git-checkout-index --stage=2 their_broken_file.c
> >> and similarly for "theirs", etc.
> >
> > Dunno. When this problem hits me, I usually do
> >
> > git diff --theirs their_broken_file.c
> >
> > anyway, to see what it is doing (colour and all). When I am satisfied,
> > that "theirs" is really what I want, I just go back one in history, and
> > append a call to git-apply like this:
> >
> > git diff --theirs their_broken_file.c | git apply --index
>
> Then
>
> git checkout --theirs their_broken_file.c
>
> is obvious simplification.
Obvious maybe. But simplification, not to me. Especially since the way I
call it, there is less possibility to shoot myself into the foot.
But then, I do not really care.
Ciao,
Dscho
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-04 11:41 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061204070021.GG1369@localdomain>
>>>>> "Eric" == Eric Wong <normalperson@yhbt.net> writes:
Eric> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>>
>> Does this ring a bell?
Eric> Nope.
Eric> This is on r15941 of https://svn.perl.org/parrot/trunk ? I can't seem
Eric> to reproduce this with git svn fetch -r15940:15941
No, and that worked for me as well. Apparently, I might have corrupted my
metadata because I updated git-svn while I was using it. Is there any way to
reset the metadata without having to re-fetch 15000 revisions?
--
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.
^ permalink raw reply
* [PATCH] gitweb: Fix Atom feed <logo>: it is $logo, not $logo_url
From: Jakub Narebski @ 2006-12-04 13:09 UTC (permalink / raw)
To: git
Fix contents of Atom feed <logo> element; it should be URL
of $logo, not URL pointed by logo link.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Do anyone use Atom feed logo? This error was from the beginning of Atom
feed generation in git.git version of gitweb, and nobody complained.
I wonder why it is <logo>URL</logo>, and not <logo href="URL" />...
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 093bd72..ffe8ce1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4282,7 +4282,7 @@ XML
}
if (defined $logo_url) {
# not twice as wide as tall: 72 x 27 pixels
- print "<logo>" . esc_url($logo_url) . "</logo>\n";
+ print "<logo>" . esc_url($logo) . "</logo>\n";
}
if (! %latest_date) {
# dummy date to keep the feed valid until commits trickle in:
--
1.4.4.1
^ permalink raw reply related
* [PATCH] git-clone: Rename --use-immingled-remote option to --no-separate-remote
From: Jakub Narebski @ 2006-12-04 13:29 UTC (permalink / raw)
To: git
With making --use-separate-remote default when creating non-bare
clone, there was need for the flag which would turn off this behavior.
It was called --use-immingled-remote.
Immingle means to blend, to combine into one, to intermingle, but it
is a bit obscure word. I think it would be better to use simply
--no-separate-remote as the opposite to --use-separate-remote
option to git clone.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-clone.txt | 4 ++--
git-clone.sh | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 4cb4223..d5efa00 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-clone' [--template=<template_directory>] [-l [-s]] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- [--use-separate-remote | --use-immingled-remote] <repository>
+ [--use-separate-remote | --no-separate-remote] <repository>
[<directory>]
DESCRIPTION
@@ -105,7 +105,7 @@ OPTIONS
of `$GIT_DIR/refs/heads/`. Only the local master branch is
saved in the latter. This is the default.
---use-immingled-remote::
+--no-separate-remote::
Save remotes heads in the same namespace as the local
heads, `$GIT_DIR/refs/heads/'. In regular repositories,
this is a legacy setup git-clone created by default in
diff --git a/git-clone.sh b/git-clone.sh
index d4ee93f..8964039 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
}
usage() {
- die "Usage: $0 [--template=<template_directory>] [--use-immingled-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
+ die "Usage: $0 [--template=<template_directory>] [--no-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
}
get_repo_base() {
@@ -140,7 +140,7 @@ while
*,--use-separate-remote)
# default
use_separate_remote=t ;;
- *,--use-immingled-remote)
+ *,--no-separate-remote)
use_separate_remote= ;;
1,--reference) usage ;;
*,--reference)
@@ -176,7 +176,7 @@ repo="$1"
test -n "$repo" ||
die 'you must specify a repository to clone.'
-# --bare implies --no-checkout and --use-immingled-remote
+# --bare implies --no-checkout and --no-separate-remote
if test yes = "$bare"
then
if test yes = "$origin_override"
--
1.4.4.1
^ permalink raw reply related
* Re: [PATCH 1/2] move Git.pm build instructions into perl/Makefile
From: Alex Riesen @ 2006-12-04 13:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64csq7e9.fsf@assigned-by-dhcp.cox.net>
On 12/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > Updated patch attached.
>
> Will apply, thanks, but with a few tweaks while I had to hand
> munge your attachment anyway.
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Karl Hasselström @ 2006-12-04 15:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Marco Costalba, git
In-Reply-To: <b0943d9e0612040117y6554b891yaf6eb59d0d52ebf0@mail.gmail.com>
On 2006-12-04 09:17:16 +0000, Catalin Marinas wrote:
> On 02/12/06, Marco Costalba <mcostalba@gmail.com> wrote:
>
> > On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Printing progress messages to stdout causes them to get mixed up
> > > with the actual output of the program. Using stderr is much
> > > better, since the user can then redirect the two components
> > > separately.
> >
> > This patch breaks qgit.
>
> Since there are other tools relying on a clean stderr, I think I
> would revert it and add a verbose flag and/or config option. Karl,
> any thoughts on this (since you sent the patch)?
I introduced this since I wanted to divert the output to a file, and
the progress message had no business being written to that file. But a
command line option to suppress progress messages would work just as
well if that's what git does.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: On removing files and "git-rm is pointless"
From: Linus Torvalds @ 2006-12-04 15:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Carl Worth, Sam Vilain
In-Reply-To: <7vd570q888.fsf@assigned-by-dhcp.cox.net>
On Mon, 4 Dec 2006, Junio C Hamano wrote:
>
> FWIW, I too am in favor of the proposed fix to "git rm" as Linus
> outlined.
Note that somebody (sorry, forget who) correctly pointed out that in order
to be "safe", the file that you "rm" has to match not only the index, but
it should match the HEAD tree too.
If it matches both the index and the HEAD tree, a "git rm filename" is
totally safe, since you can always get it back by just doing a
git checkout HEAD filename
so the "git rm" really didn't lose any info, and as such, we can _happily_
remove the working tree copy without any concern at all.
If it doesn't match HEAD, we can't get it back as easily, so maybe that's
the case when we want to have "git rm -f filename".
(And obviously, for all the normal reasons, if the index or HEAD doesn't
match, the error message should be helpful and also explicitly mention the
"-f" flag. Somehing like
file 'x' does not match HEAD or has been staged for changes.
Will not remove. Use '-f' to force removal.
("has been staged for changes" is just a long way of saying "index". See?
I _can_ learn.)
^ permalink raw reply
* Re: On removing files and "git-rm is pointless"
From: Jakub Narebski @ 2006-12-04 16:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>
Linus Torvalds wrote:
> (And obviously, for all the normal reasons, if the index or HEAD doesn't
> match, the error message should be helpful and also explicitly mention the
> "-f" flag. Somehing like
>
> file 'x' does not match HEAD or has been staged for changes.
> Will not remove. Use '-f' to force removal.
>
> ("has been staged for changes" is just a long way of saying "index". See?
> I _can_ learn.)
I'd rather have
File 'x' does not match HEAD or index (has been staged for changes).
Will not remove. Use "git rm -f 'x'" to force removal.
I'd rather not learn that "staged for changes" mean "index". I'm quote
comfortable with the concept of "index" and the name "index",
thankyouverymuch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: On removing files and "git-rm is pointless"
From: Olivier Galibert @ 2006-12-04 16:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Nicolas Pitre, git, Carl Worth, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>
<pet_peeve>
On Mon, Dec 04, 2006 at 07:42:26AM -0800, Linus Torvalds wrote:
> (And obviously, for all the normal reasons, if the index or HEAD doesn't
> match, the error message should be helpful and also explicitly mention the
> "-f" flag. Somehing like
>
> file 'x' does not match HEAD or has been staged for changes.
> Will not remove. Use '-f' to force removal.
And you wouldn't tell which, you stupid computer?
I hate when error messages go "there is a problem that may be x, y or
z. You can figure out which one yourself.".
Incidentally, splitting the message would allow you to add a "use git
diff x" or a "use git diff --cached x to see the differences" message.
</pet_peeve>
^ permalink raw reply
* [PATCH take 3] make 'git add' a first class user friendly interface to the index
From: Nicolas Pitre @ 2006-12-04 16:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This brings the power of the index up front using a proper mental model
without talking about the index at all. See for example how all the
technical discussion has been evacuated from the git-add man page.
Any content to be committed must be added together. Whether that
content comes from new files or modified files doesn't matter. You
just need to "add" it, either with git-add, or by providing
git-commit with -a (for already known files only of course).
No need for a separate command to distinguish new vs modified files
please. That would only screw the mental model everybody should have
when using GIT.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
This time I incorporated the few remaining suggestions about
formulation, etc. I think it should be it.
Documentation/git-add.txt | 53 +++++++++++++++++++++++--------------------
Documentation/tutorial.txt | 46 +++++++++++++++++++++++++++++++++-----
builtin-add.c | 6 ++--
wt-status.c | 2 +-
4 files changed, 72 insertions(+), 35 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 6342ea3..16fef1c 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -3,7 +3,7 @@ git-add(1)
NAME
----
-git-add - Add files to the index file
+git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
@@ -11,16 +11,31 @@ SYNOPSIS
DESCRIPTION
-----------
-A simple wrapper for git-update-index to add files to the index,
-for people used to do "cvs add".
+All the changed file contents to be committed together in a single set
+of changes must be "added" with the 'add' command before using the
+'commit' command. This is not only for adding new files. Even modified
+files must be added to the set of changes about to be committed.
-It only adds non-ignored files, to add ignored files use
+This command can be performed multiple times before a commit. The added
+content corresponds to the state of specified file(s) at the time the
+'add' command is used. This means the 'commit' command will not consider
+subsequent changes to already added content if it is not added again before
+the commit.
+
+The 'git status' command can be used to obtain a summary of what is included
+for the next commit.
+
+This command only adds non-ignored files, to add ignored files use
"git update-index --add".
+Please see gitlink:git-commit[1] for alternative ways to add content to a
+commit.
+
+
OPTIONS
-------
<file>...::
- Files to add to the index (see gitlink:git-ls-files[1]).
+ Files to add content from.
-n::
Don't actually add the file(s), just show if they exist.
@@ -34,27 +49,12 @@ OPTIONS
for command-line options).
-DISCUSSION
-----------
-
-The list of <file> given to the command is fed to `git-ls-files`
-command to list files that are not registered in the index and
-are not ignored/excluded by `$GIT_DIR/info/exclude` file or
-`.gitignore` file in each directory. This means two things:
-
-. You can put the name of a directory on the command line, and
- the command will add all files in it and its subdirectories;
-
-. Giving the name of a file that is already in index does not
- run `git-update-index` on that path.
-
-
EXAMPLES
--------
git-add Documentation/\\*.txt::
- Adds all `\*.txt` files that are not in the index under
- `Documentation` directory and its subdirectories.
+ Adds content from all `\*.txt` files under `Documentation`
+ directory and its subdirectories.
+
Note that the asterisk `\*` is quoted from the shell in this
example; this lets the command to include the files from
@@ -62,15 +62,18 @@ subdirectories of `Documentation/` directory.
git-add git-*.sh::
- Adds all git-*.sh scripts that are not in the index.
+ Considers adding content from all git-*.sh scripts.
Because this example lets shell expand the asterisk
(i.e. you are listing the files explicitly), it does not
- add `subdir/git-foo.sh` to the index.
+ consider `subdir/git-foo.sh`.
See Also
--------
+gitlink:git-status[1]
gitlink:git-rm[1]
-gitlink:git-ls-files[1]
+gitlink:git-mv[1]
+gitlink:git-commit[1]
+gitlink:git-update-index[1]
Author
------
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index fe4491d..361cb8e 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -87,14 +87,48 @@ thorough description. Tools that turn commits into email, for
example, use the first line on the Subject line and the rest of the
commit in the body.
-To add a new file, first create the file, then
-------------------------------------------------
-$ git add path/to/new/file
-------------------------------------------------
+Git tracks content not files
+----------------------------
+
+With git you have to explicitly "add" all the changed _content_ you
+want to commit together. This can be done in a few different ways:
+
+1) By using 'git add <file_spec>...'
+
+ This can be performed multiple times before a commit. Note that this
+ is not only for adding new files. Even modified files must be
+ added to the set of changes about to be committed. The "git status"
+ command gives you a summary of what is included so far for the
+ next commit. When done you should use the 'git commit' command to
+ make it real.
+
+ Note: don't forget to 'add' a file again if you modified it after the
+ first 'add' and before 'commit'. Otherwise only the previous added
+ state of that file will be committed. This is because git tracks
+ content, so what you're really 'add'ing to the commit is the *content*
+ of the file in the state it is in when you 'add' it.
+
+2) By using 'git commit -a' directly
+
+ This is a quick way to automatically 'add' the content from all files
+ that were modified since the previous commit, and perform the actual
+ commit without having to separately 'add' them beforehand. This will
+ not add content from new files i.e. files that were never added before.
+ Those files still have to be added explicitly before performing a
+ commit.
+
+But here's a twist. If you do 'git commit <file1> <file2> ...' then only
+the changes belonging to those explicitly specified files will be
+committed, entirely bypassing the current "added" changes. Those "added"
+changes will still remain available for a subsequent commit though.
+
+However, for normal usage you only have to remember 'git add' + 'git commit'
+and/or 'git commit -a'.
+
-then commit as usual. No special command is required when removing a
-file; just remove it, then tell `commit` about the file as usual.
+Viewing the changelog
+---------------------
At any point you can view the history of your changes using
diff --git a/builtin-add.c b/builtin-add.c
index febb75e..b3f9206 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -94,9 +94,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
newfd = hold_lock_file_for_update(&lock_file, get_index_file(), 1);
- if (read_cache() < 0)
- die("index file corrupt");
-
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -131,6 +128,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
return 0;
}
+ if (read_cache() < 0)
+ die("index file corrupt");
+
for (i = 0; i < dir.nr; i++)
add_file_to_index(dir.entries[i]->name, verbose);
diff --git a/wt-status.c b/wt-status.c
index de1be5b..4b8b570 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -163,7 +163,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
int i;
if (q->nr)
wt_status_print_header("Changed but not updated",
- "use git-update-index to mark for commit");
+ "use git-add on files to include for commit");
for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
if (q->nr)
--
1.4.4.1.gc419-dirty
^ permalink raw reply related
* Re: [PATCH]: Pass -M to diff in request-pull
From: Linus Torvalds @ 2006-12-04 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Miller, git
In-Reply-To: <7v3b7wrrcr.fsf@assigned-by-dhcp.cox.net>
On Mon, 4 Dec 2006, Junio C Hamano wrote:
> David Miller <davem@davemloft.net> writes:
> >
> > Linus recommended this, otherwise any renames cause the
> > diffstate output to be rediculious in some circumstances :)
>
> Thanks, but "rediculious"?
Kernel dewalopers can't speel. We all knew that.
At least we don't do 1337-sp33k.
^ permalink raw reply
* Re: Set permissions of each new file before "cvs add"ing it.
From: Robin Rosenberg @ 2006-12-04 16:51 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87ac24zrk0.fsf@rho.meyering.net>
söndag 03 december 2006 20:51 skrev Jim Meyering:
> Without the following patch, git-cvsexportcommit would fail to propagate
> permissions of files added in git to the CVS repository. I.e., when I
> added an executable script in coreutils' git repo, then tried to propagate
> that addition to the mirroring CVS repository, the script ended up added
> not executable there.
The patch to cvsexportcommit I sent a couple of weeks ago fixes the execution
bit, along with most other flaws. Jounio had some objections that I haven't
fixed yet. Hacking the Eclipse plugin was much more fun :)
I added this test case just to verify it on top of my previous patch.
-- robin
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 75b9f38..63eafc8 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -195,4 +195,19 @@ test_expect_success \
! git-cvsexportcommit -c $id
)'
+test_expect_success \
+ 'Retain execute bit' \
+ 'mkdir G &&
+ echo executeon >G/on &&
+ chmod +x G/on &&
+ echo executeoff >G/off &&
+ git add G/on &&
+ git add G/off &&
+ git commit -a -m "Execute test" &&
+ (cd "$CVSWORK" &&
+ git-cvsexportcommit -c HEAD
+ test -x G/on &&
+ ! test -x G/off
+ )'
+
^ permalink raw reply related
* Seeing added and removed files between two tree states
From: Alex Bennee @ 2006-12-04 17:25 UTC (permalink / raw)
To: git
In there a way to see just what files where added between two points in
the tree? I want something better than parsing the diffstat.
I thought git-ls-files -ad comittish..comitishb would do the trick but
it seems not.
--
Alex, homepage: http://www.bennee.com/~alex/
... at least I thought I was dancing, 'til somebody stepped on my hand.
-- J. B. White
^ 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