* Re: pull-fetch-param.txt
From: Julian Phillips @ 2007-07-20 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git
In-Reply-To: <7vbqe7xbvq.fsf@assigned-by-dhcp.cox.net>
On Fri, 20 Jul 2007, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
>
>>> I'll check with the docbook-xsl Debian maintainer.
>>
>> The change in docbook-xsl was by intention, please see
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22
>
> Hmph. Where does that leave us poor users who would want to
> support both 1.71 and 1.72, I wonder...
>
> Will they have the same revert in 1.73 for that House Sign, too?
It looks like they do, so perhaps we could just say that you will have
issues building the git docs with 1.72 and ignore my last patch?
(comparing http://docbook.xml-doc.org/snapshots/xsl/manpages/utility.xsl
which has today's date and uses . and \ against
http://docbook.sourceforge.net/release/xsl/1.72.0/manpages/utility.xsl
which uses U+2302 and U+2593)
--
Julian
---
Old MacDonald had an agricultural real estate tax abatement.
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Junio C Hamano @ 2007-07-20 16:45 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070720143214.23897.qmail@511f57d39b0a54.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
>> I'll check with the docbook-xsl Debian maintainer.
>
> The change in docbook-xsl was by intention, please see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22
Hmph. Where does that leave us poor users who would want to
support both 1.71 and 1.72, I wonder...
Will they have the same revert in 1.73 for that House Sign, too?
^ permalink raw reply
* Re: [PATCH] Update listingblock monospace fix to support all docbook versions
From: Junio C Hamano @ 2007-07-20 16:42 UTC (permalink / raw)
To: Julian Phillips; +Cc: Fredrik Tolf, git
In-Reply-To: <20070720121153.23352.73276.julian@quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> So this uses the string '#GIT#SET#MAN#FONT#', and then changes that to
> .ft using a post-process perl script.
>
> Not pretty, but it works.
Owwwww... pain.
Unless anybody else has better fix I'd say we go with this.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Linus Torvalds @ 2007-07-20 15:31 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Brian Gernhardt, Shawn O.Pearce, Matthieu Moy,
Johannes Schindelin, Git Mailing List
In-Reply-To: <85sl7jty43.fsf@lola.goethe.zz>
On Fri, 20 Jul 2007, David Kastrup wrote:
>
> Like "." destroyed the fundamental concepts of Unix filesystems.
David, I'd suggest you just be quiet and learn, instead of spouting
idiotic nonsense.
When Junio talks about fundamental concepts of git, you should sit back,
relax, and ponder. And maybe realize that the git filesystem isn't a "unix
filesystem". It's a content-addressable one, it's not POSIX, and yes, it
really does have totally different fundamental concepts.
So your arguments are just inane and stupid, and show that you aren't
worth discussing with, because you don't even understand what you are
talking about.
So here's a suggestion: how about trying to *understand* git first. After
that, you can talk.
In fact, at this point, I have an even better suggestion: how about you
just shut the hell up until you have a tested patch? Code talks, bullshit
walks. And right now you are nothing but bullshit.
Linus
^ permalink raw reply
* qgit: failed assertion involving unapplied stgit patches
From: Yann DIRSON @ 2007-07-20 14:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: ydirson, git
Hi Marco,
qgit 1.5.6 cannot show me the blame window for a given file, it complains
with the following errors:
ASSERT in getAncestor: ancestor of b617a11b801993b917e1598fd6c5a135ea74ce6f
not found
ASSERT in lookupAnnotation: no annotation for
FELIN1_DRIVERS/spi/mpc5200_spi.c
The commit for which it cannot find an ancestor is an unapplied patch,
whose preceding patch has been refreshed already (ie. there is no ref
pointing to the parent commit), and I suspect this could be the reason for
the failure. At least once I have pushed this patch and popped it again,
the assertion does not show any more.
However, I'm not sure why it walks this part of the tree, since the
per-file history view does not show unapplied patches (it would be great to
see them, though, as well as showing applied patches as such).
Best regards,
--
Yann
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin.
From: Kristian Høgsberg @ 2007-07-20 14:45 UTC (permalink / raw)
To: Carlos Rica; +Cc: git
In-Reply-To: <1b46aba20707181427y12bd8b62pe30df61219e7c1f7@mail.gmail.com>
On Wed, 2007-07-18 at 23:27 +0200, Carlos Rica wrote:
> 2007/7/18, Kristian Høgsberg <krh@redhat.com>:
> > + if (buffer) {
> > + len = strip_lines(buffer, len);
> > +
> > + if (fwrite(buffer, 1, len, fp) < len)
> > + die("could not write commit template: %s\n",
> > + strerror(errno));
> > + }
> ....
> > + len = strip_lines(buffer, len);
> > +
> > + if (message_is_empty(buffer, len))
> > + die("* no commit message? aborting commit.");
> > +
>
> Hi Kristian, you could call to the new stripspace() function
> in builtin-stripspace.c, to reduce code in your file. The only
> thing you should consider is that the new stripspace()
> removes always the last '\n' in the file (if any), so you have to
> add it when you need.
Yup, I'm keeping an eye on all your changes, and it looks like it's all
falling in place nicely. Once I have the last few pieces of
functionality ported over I'll rebase and update builtin-commit to use
the new functionality you've landed.
A couple of things that might be interesting right now is: 1) pick out
the test case I made for commit and get it upstream, and 2) take the
changes I did to wt-status.c (making it able to run on a different index
and output to a specified FILE pointer) and get that upstream.
cheers,
Kristian
^ permalink raw reply
* Re: pull-fetch-param.txt
From: Gerrit Pape @ 2007-07-20 14:32 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <20070713074824.9806.qmail@df2dc1a3890a6b.315fe32.mid.smarden.org>
On Fri, Jul 13, 2007 at 07:48:24AM +0000, Gerrit Pape wrote:
> On Fri, Jul 13, 2007 at 12:17:34AM -0700, Junio C Hamano wrote:
> > Sorry, does not reproduce for me, with asciidoc 8.2.1. There
> > must be something different between our environments.
>
> Yes, I have docbook-xsl 1.72.0.
> > $ git commit \-a \-c ORIG_HEAD \fB(3)\fR
>
> I get the same with docbook-xsl 1.71.0, but with 1.72.0:
> $ git commit \-a \-c ORIG_HEAD \efB(3)\efR
> I'll check with the docbook-xsl Debian maintainer.
The change in docbook-xsl was by intention, please see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420114#22
Regards, Gerrit.
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-20 13:33 UTC (permalink / raw)
To: git
In-Reply-To: <200707201520.55911.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Friday 20 July 2007, David Kastrup wrote:
>> Johan Herland <johan@herland.net> writes:
>
>> > 4. Whether or not git should track directories by default. You
>> > say yes, I say no.
>>
>> Element of least surprise. But since my proposal allows easy and
>> intuitive declaration of the preference at user, project, and
>> directory level without one choice messing with the choice of other
>> projects and contributors with mixed preferences, this is quite
>> unimportant.
>>
>> We are in agreement that adding or removing the tracking explicitly
>> for a single directory might be useful to have. But it can't be
>> the only way.
>
> As long as you can add/remove tracking recursively for a whole
> (sub)tree, I don't see what's the problem.
Neither do I. But a --directory option never is recursive. That is
the whole point.
Probably we are in violent agreement again.
> Of course, if you want to change the default behaviour, you should
> be able either set a config variable somewhere, or - as a last
> resort - alias git-add and git-rm to always supply the appropriate
> command-line option.
Or declare diverging behaviors using a !. or . entry in the gitignore
mechanisms. Which work everywhere where we need them.
>> > 5. How the tracking of directories should be implemented in git's
>> > object database. I want to keep the index/tree as-is except for
>> > adding directory entries (w/mode 040000) for the tracked
>> > directories only. You seem to want to add directory entries for
>> > _all_ directories and then additional "." entries for directories
>> > you don't want deleted if/when empty.
>>
>> No. I don't want to change _anything_ for untracked directories.
>> They are, as previously, implied by the contents and have a "tree"
>> entry for efficiency reasons. Nothing new here.
>>
>> The directory mode entries are named "." and are for tracked
>> directories only.
>
> Ok. So our difference in opinion on implementation is even smaller
> than I imagined; basically only whether the directory is tracked by
> a mode "040000" entry, or by a "." entry.
Actually, even smaller: I'd track them by a "." entry with mode
1777755755 or whatever is the natural expression for "this is a
directory". The mode would be different from the existing "this is a
tree".
_If_ one wants at one time track permissions of files apart from "x",
the "." entry would be natural for carrying directory permissions.
Without ".", you basically tell git "I don't care about the existence
of this directory. Just do what is necessary for checking out my
files".
>> > Am I making sense, or have I misunderstood our misunderstandings?
>>
>> The latter. You are violently arguing for what I outlined. Which
>> probably shows that I am not the best at explaining my ideas, and
>> that it reflects badly upon them.
>
> That probably goes for both of us :)
>
> Well, as long as we have this clarified, I don't see much point in
> continuing this part of the thread. I feel confident that the git
> community as a whole will converge on the best technical solution,
> once it surfaces.
I'll probably crank out some insolently primitive proof of concept
eventually.
--
David Kastrup
^ permalink raw reply
* Re: Feedback on native Win32 git from a Perl perspective
From: Martin Langhoff @ 2007-07-20 13:32 UTC (permalink / raw)
To: Adam Kennedy; +Cc: git
In-Reply-To: <46A06C7F.5010601@phase-n.com>
On 7/20/07, Adam Kennedy <adam@phase-n.com> wrote:
> A quick review of native Win32 git provoked by the current conversation
> amoungst the Perl core maintainers about changing version control
> systems and whether to go with svn or git (the main two candidates).
Hi Adam,
The problem you hit is that you need the MinGW runtime -- I forget its
name -- and that will have installed an item in your start menu. It's
for a terminal that has all the MinGW stuff, you get a nice bash
shell. I opened, added the GIT install directory to the path, and was
all set.
I think Sam Vilain (aka mugwump) is going to / at / returning from
OSCON this week, so he migth take a while to reply. Oh, I see he
posted in your blog too.
He's been running imports of the Perl dev trees into git, they'll be
at http://git.catalyst.net.nz/gitweb - fetchable via http at
http://git.catalyst.net.nz/git/perl.git
My notes above are because I have _just_ been setting up git at
aclient site on Win32. Took me a bit of fiddling as I hadn't used
Windows in years, but I got it going...
- needs the mingw runtime - trivial
- runs pretty well from the commandline - impressed
- gitk and other Tk-based utilities work great ( _very_ impressed)
but I had to fixup the wish executable name - minor
- the http protocol wasn't supported out of the box in the version I
got, a pain for anon checkouts, and I've seen some discussion about
that on the list -- unsure here
In terms of http support -- IIRC the problem is handling of forked
processes, but there might be a way to sidestep the problem. Very
early versions of git did some odd curl cmdline that Cogito copied.
Serialised, slow and not one bit as smart as what we do now, but we
can perhaps reuse some of that.
Some things you point out can be improved once things are more
polished -- like adding links to gitk and git gui but we'd need to
sort out how to do this in a directory context. Heh - maybe we need
one of those explorer.exe extensions...
>From a "we are very limited Windows users" POV, no, we don't have
TortoiseSVN unfortunately. But for developers used to mixed cli/gui
environments, like I'm sure most Perl developers are, it'll be a
breeze. It does need a bit of a howto though.
> For reference, the reviewer (me) has 10 years of experience with Perl
> development across both Windows, Linux, BSD, Solaris, Mac (old and new).
I'm guess in general terms I have a somewhat similar bg -- though I
don't develop Perl ;-) -- and perhaps it's a bit of luck. I had
_never_ seen MinGW (I do know CygWin) and perhaps it was a stroke of
luck that it only took me about 45 minutes to get things going,
figuring out the stuff noted above.
cheers,
martin
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: David Kastrup @ 2007-07-20 13:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5svxt1f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Actually, I do not think there is absolute right or wrong here. The
> difference is not that the information is at the "right" or "wrong"
> place, but one approach places the information at more
> efficient-to-use place than the other.
Agreed.
> In that sense, the attribute approach _is_ a more elegant solution
> between the two.
Disagreed. See below.
> Making it an attribute has a huge practical advantage.
>
> By treating executable bit as a piece metadata, we can compare the
> "contents" quickly. If you "chmod +x" a blob without changing
> anything else, we can detect that fact, because blob object names
> are equal. At the philosophical level, you _could_ argue that the
> executable-ness is one bit of content and include that in the object
> name computation for the blob. There is nothing fundamentally wrong
> about that approach, but that destroys the nice "cheap
> comparability" between blobs that differ only by executable-ness.
>
> David's "." in tree is essentially the same argument as treating the
> executable-ness as one extra bit of content. The fact that a
> particular tree wants to stay even after emptied can be treated as
> part of contents (thereby reflected in its object name).
Small nit here: the tree does not want to stay after emptied, since it
is not empty as long as it contains ".".
> There is nothing fundamentally wrong there, either. But that means
> two trees that contain otherwise identical set of blobs and
> subtrees, but differ only in the behaviour of when they are emptied,
> would get different object names, hence you need to descend into
> them to see if they are different.
And here we disagree in our assessment, and where I find the example
of the execute bit unfitting. We are talking about _trees_ here, not
files. So this is only relevant if we have a _huge_, _flat_ tree with
_lots_ of entries at _bottom_ level.
How often does it occur in practice that a _large_ tree has "." added
or removed and nothing else changes? Never, because the normal use
case is that a directory is either tracked from the start, or not
tracked at all. And even if you change the tracking for a whole
project at once (which is a one-time job): the cost difference is
looking at all _tree_ leaf entries, not at all the involved files.
> Using attribute that is detached from the content itself allows you
> to hoist that one bit one level up. By treating executable-ness not
> as part of content, we can compare two blobs with different
> executable bits cheaply. You can avoid descending into such a tree
> when comparing it with another tree that is different only by the
> "will-stay-when-emptied"-ness the same way.
But changing the executable bit of a file will happen often during
development. Adding or removing "." will never usually be done _ever_
except when the tree is first created or removed, and then the cost is
negligible.
So "performance" is not an issue for making this an attribute or a
flat entry. While the user level abstraction need not match the
actual representation, I think that it will make for lot less special
cases and problematic behavior to pull through with "." as a directory
entry that mostly behaves like other files and, like other files,
requires git to create a directory to contain it. All the logic for
creating and deleting directories and creating and adding and ignoring
files can _perfectly_ stay the same.
There are just two differences:
a) git always sees "." as a file in every directory in the work tree
and considers it a file.
b) when it comes to actually creating or modifying or reading the
actual file in the work directory, it silently skips the
operation.
It would not even be necessary to give the directory entry any special
attributes or permissions to make this scheme work: declaring it a
normal file and just special-casing the name "." on those operations
would lead to consistent and working behavior, with no change of
format in index and repository at all.
Possibly even a) alone would suffice, at the cost of letting git
complain and continue at every operation (or making a _really_ royal
mess for Solaris root users).
I might be tempted to make a proof-of-concept patch for that.
But for backward-compatibility, it will be better to use an entry type
which old versions of git will be able to ignore when checking out or
in. And for user-friendliness, one does not really want to list such
entries as regular files.
--
David Kastrup
^ permalink raw reply
* Re: Empty directories...
From: Johan Herland @ 2007-07-20 13:20 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86odi7utdj.fsf@lola.quinscape.zz>
On Friday 20 July 2007, David Kastrup wrote:
> Johan Herland <johan@herland.net> writes:
>
> > AFAICS, from a high-level POV, we're pretty much in agreement on the
> > following points:
> >
> > 1. Git should be able to track directories.
> >
> > 2. Tracked directories should be kept alive, even if empty.
> >
> > 3. Git must not necessarily track _all_ directories.
> >
> >
> > Conversely, we seem to disagree on these points:
> >
> > 4. Whether or not git should track directories by default. You say
> > yes, I say no.
>
> Element of least surprise. But since my proposal allows easy and
> intuitive declaration of the preference at user, project, and
> directory level without one choice messing with the choice of other
> projects and contributors with mixed preferences, this is quite
> unimportant.
>
> We are in agreement that adding or removing the tracking explicitly
> for a single directory might be useful to have. But it can't be the
> only way.
As long as you can add/remove tracking recursively for a whole (sub)tree, I
don't see what's the problem. Of course, if you want to change the default
behaviour, you should be able either set a config variable somewhere, or - as
a last resort - alias git-add and git-rm to always supply the appropriate
command-line option.
> > 5. How the tracking of directories should be implemented in git's
> > object database. I want to keep the index/tree as-is except for
> > adding directory entries (w/mode 040000) for the tracked directories
> > only. You seem to want to add directory entries for _all_
> > directories and then additional "." entries for directories you
> > don't want deleted if/when empty.
>
> No. I don't want to change _anything_ for untracked directories.
> They are, as previously, implied by the contents and have a "tree"
> entry for efficiency reasons. Nothing new here.
>
> The directory mode entries are named "." and are for tracked
> directories only.
Ok. So our difference in opinion on implementation is even smaller than I
imagined; basically only whether the directory is tracked by a mode "040000"
entry, or by a "." entry.
> > Am I making sense, or have I misunderstood our misunderstandings?
>
> The latter. You are violently arguing for what I outlined. Which
> probably shows that I am not the best at explaining my ideas, and that
> it reflects badly upon them.
That probably goes for both of us :)
Well, as long as we have this clarified, I don't see much point in continuing
this part of the thread. I feel confident that the git community as a whole
will converge on the best technical solution, once it surfaces.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Feedback on native Win32 git from a Perl perspective
From: Adam Kennedy @ 2007-07-20 8:04 UTC (permalink / raw)
To: git
It was suggested that this link be fired through to this address.
http://use.perl.org/~Alias/journal/33825
A quick review of native Win32 git provoked by the current conversation
amoungst the Perl core maintainers about changing version control
systems and whether to go with svn or git (the main two candidates).
This review is utterly unrelated to whether or not central or
distributed version control is better, and utterly unrelated to the
features of git itself, and refer only to the native Win32 git
installer/package itself.
For reference, the reviewer (me) has 10 years of experience with Perl
development across both Windows, Linux, BSD, Solaris, Mac (old and new).
I'm also a CPAN administrator, Perl toolchain maintainer, author of
about 150 cross-platform Perl packages on the CPAN, and creator of the
"Strawberry Perl" Win32 Perl distribution and win32.perl.org website.
If you have any follow up, please CC me.
Thanks
Adam Kennedy
^ permalink raw reply
* Re: Empty directories...
From: Johan Herland @ 2007-07-20 12:18 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86tzrzuyyy.fsf@lola.quinscape.zz>
On Friday 20 July 2007, David Kastrup wrote:
> Johan Herland <johan@herland.net> writes:
> > My point is fundamentally that selectively tracking directories is a
> > more powerful concept than just tracking _all_ directories by
> > default.
>
> Perhaps you might read up on some of the past discussion before
> beating dead horses. This has been covered already, and more than
> once. I never asked for "all directories" to be tracked. I outlined
> cases where they are tracked and where not, and I tested that the
> mechanisms in "man gitignore" already work _perfectly_ with the
> pattern "." for configuring the _implied_ tracking at directory,
> repository, project, and user preference level.
It seems our discussion is based on so many misunderstandings of each other
that it's not very useful to reply to specific parts of it.
AFAICS, from a high-level POV, we're pretty much in agreement on the following
points:
1. Git should be able to track directories.
2. Tracked directories should be kept alive, even if empty.
3. Git must not necessarily track _all_ directories.
Conversely, we seem to disagree on these points:
4. Whether or not git should track directories by default. You say yes, I say
no.
5. How the tracking of directories should be implemented in git's object
database. I want to keep the index/tree as-is except for adding directory
entries (w/mode 040000) for the tracked directories only. You seem to want to
add directory entries for _all_ directories and then additional "." entries
for directories you don't want deleted if/when empty.
Am I making sense, or have I misunderstood our misunderstandings?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] Update listingblock monospace fix to support all docbook versions
From: Julian Phillips @ 2007-07-20 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Tolf, git
In-Reply-To: <Pine.LNX.4.64.0707200806540.20056@beast.quantumfyre.co.uk>
The previous fix to force the listingblock to be monospaced would not
work for docbook versions 1.72 or newer, as they now escape leading
'.'s and you have to use U+2302 instead. However you can't use U+2302
in ealier versions ...
So this uses the string '#GIT#SET#MAN#FONT#', and then changes that to
.ft using a post-process perl script.
Not pretty, but it works.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
On Fri, 20 Jul 2007, Julian Phillips wrote:
> On Fri, 20 Jul 2007, Junio C Hamano wrote:
>
>> Julian Phillips <julian@quantumfyre.co.uk> writes:
>>
>> > In order for these roff commands to get through to the manpage they
>> > have to be element encoded to prevent quoting. In particular with
>> > docbook xsl 1.72.0 and newer we have to use U+2302 instead of . to
>> > prevent the roff command being escaped. We also add a small perl
>> > script for docbook < 1.72.0.
>>
>> This does not work at all for docbook 1.71. I get "^<TAB>ft C"
>> as output from xmlto.
>
> Oh, well ... that's handy? :S
>
> I've just checked, and I do have a machine with docbook < 1.72, so I'll see
> if I can get something working on both. Probably early next week since I'm
> away this weekend.
This works ... but I'm not particularly proud of it.
I've done this a patch ontop of master, since you seem to have already pushed
out the tweaked version of my original patch.
Documentation/Makefile | 3 +++
Documentation/asciidoc.conf | 4 ++--
Documentation/insert_man_font_commands.pl | 6 ++++++
3 files changed, 11 insertions(+), 2 deletions(-)
create mode 100755 Documentation/insert_man_font_commands.pl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index b062757..70f4b44 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -121,6 +121,9 @@ clean:
%.1 %.5 %.7 : %.xml
xmlto -m callouts.xsl man $<
+ mv $@ $@.tmp
+ ./insert_man_font_commands.pl < $@.tmp > $@
+ $(RM) $@.tmp
%.xml : %.txt
$(RM) $@+ $@
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index af5b155..83fa03f 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -28,11 +28,11 @@ ifdef::backend-docbook[]
<example><title>{title}</title>
<literallayout>
ifdef::doctype-manpage[]
- .ft C
+ #GIT#SET#MAN#FONT# C
endif::doctype-manpage[]
|
ifdef::doctype-manpage[]
- .ft
+ #GIT#SET#MAN#FONT#
endif::doctype-manpage[]
</literallayout>
{title#}</example>
diff --git a/Documentation/insert_man_font_commands.pl b/Documentation/insert_man_font_commands.pl
new file mode 100755
index 0000000..c100534
--- /dev/null
+++ b/Documentation/insert_man_font_commands.pl
@@ -0,0 +1,6 @@
+#!/usr/bin/perl -w
+
+while ($line = <>) {
+ $line =~ s/^#GIT#SET#MAN#FONT#/.ft/;
+ print $line;
+}
--
1.5.2.2
^ permalink raw reply related
* [PATCH 2/2] builtin-tag: fix uninitialized variables
From: Johannes Schindelin @ 2007-07-20 12:07 UTC (permalink / raw)
To: git, gitster, jasampler
The function launch_editor() expects the variables 'buffer' and 'size'
to be initialized, either to an existing buffer, or to NULL and 0.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This is only called 2/2, because I found this error by testing
1/2...
builtin-tag.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index cf36def..81d37ce 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -253,9 +253,9 @@ static void create_tag(const unsigned char *object, const char *tag,
char *message, int sign, unsigned char *result)
{
enum object_type type;
- char header_buf[1024], *buffer;
+ char header_buf[1024], *buffer = NULL;
int header_len, max_size;
- unsigned long size;
+ unsigned long size = 0;
type = sha1_object_info(object, NULL);
if (type <= 0)
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* [PATCH 1/2] launch_editor(): Heed GIT_EDITOR and core.editor settings
From: Johannes Schindelin @ 2007-07-20 12:06 UTC (permalink / raw)
To: git, gitster, jasampler
In the commit 'Add GIT_EDITOR environment and core.editor
configuration variables', this was done for the shell scripts.
Port it over to builtin-tag's version of launch_editor(), which
is just about to be refactored into editor.c.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-tag.c | 6 +++++-
cache.h | 2 ++
config.c | 5 +++++
environment.c | 1 +
4 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 507f510..cf36def 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -24,7 +24,11 @@ static void launch_editor(const char *path, char **buffer, unsigned long *len)
const char *args[3];
int fd;
- editor = getenv("VISUAL");
+ editor = getenv("GIT_EDITOR");
+ if (!editor && editor_program)
+ editor = editor_program;
+ if (!editor)
+ editor = getenv("VISUAL");
if (!editor)
editor = getenv("EDITOR");
diff --git a/cache.h b/cache.h
index 1b88d75..0c12ce8 100644
--- a/cache.h
+++ b/cache.h
@@ -564,6 +564,8 @@ extern char *pager_program;
extern int pager_in_use;
extern int pager_use_color;
+extern char *editor_program;
+
/* base85 */
int decode_85(char *dst, const char *line, int linelen);
void encode_85(char *buf, const unsigned char *data, int bytes);
diff --git a/config.c b/config.c
index bdbfdec..9d8e9dc 100644
--- a/config.c
+++ b/config.c
@@ -431,6 +431,11 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.editor")) {
+ editor_program = xstrdup(value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 04d06b6..2e9d505 100644
--- a/environment.c
+++ b/environment.c
@@ -33,6 +33,7 @@ size_t delta_base_cache_limit = 16 * 1024 * 1024;
char *pager_program;
int pager_in_use;
int pager_use_color = 1;
+char *editor_program;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
int show_commit_annotations;
--
1.5.3.rc1.16.g9d6f-dirty
^ permalink raw reply related
* Git doesn't like symlinks?
From: Rogan Dawes @ 2007-07-20 11:19 UTC (permalink / raw)
To: Git Mailing List
Hi folks,
I have been tasked with doing some development against an external SVN
repo, and keeping it largely in sync with an internal directory.
Seeing as how this is a git list, I obviously decided to do this using
git :-)
So, I have a local git repo with my local changes from the SVN repo, and
I can push them to the SVN repo without too many problems. The problem
arises when I try to sync with the local directory.
Since the local directory's structure doesn't match the repo exactly, I
figured I could work around that by using a symlink to get to the right
place.
ie. the local dir is
C:\local\blah\release\5.2\<contents>
and the structure of the SVN (and hence git) repo is:
/top/main/<contents>
where <contents> is/should be identical between the two places.
Obviously, git won't work correctly in the local dir, so I tried the
following (on Cygwin)
$ cd /tmp
$ ~/git/contrib/workdir/git-new-workdir /my/git/repo/ repo-local
$ cd repo-local/top
$ rm -rf main/
$ ln -s /c/local/blah/release/5.2/ main/
$ git status
This worked, and showed me that there were a few files out of sync.
I decided to copy over one of the files from git to the local dir:
$ git checkout top/main/some/file
And git deleted my "main" symlink, and replaced it with a real dir,
containing "some/file".
Everything _else_ was now "missing".
Any ideas on how I can get this to work? I know this is not strictly
what git was designed for, but it could do a really good job if it would
only leave my symlink alone.
Rogan
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Christian Stimming @ 2007-07-20 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Brett Schwarz, git, Paul Mackerras
In-Reply-To: <20070720050455.GN32566@spearce.org>
Quoting "Shawn O. Pearce" <spearce@spearce.org>:
> Brett Schwarz <brett_schwarz@yahoo.com> wrote:
>> This is a good idea. However, I assume the _ proc is just sugar. It
>> might be better to follow a more "standard" way for this, and just
>> import the msgcat namespace, and then you can just use [mc].
>>
>> package require msgcat
>> namespace import ::msgcat::*
>> .
>> .
>> .mbar add cascade -label [mc Repository] -menu .mbar.repository
>
> Not just better, I'd prefer it. The proc name "_" is cute but
> is just too darn short. I would much prefer to use "mc" and just
> say that "mc" in all of git-gui's namespaces is reserved for the
> message catalog
I used (and prefer) "_" because that's the standard function name for
i18n'd strings when using gettext (talking about a "standard" way). In
that case the convention from C simply carries over to tcl/tk, and
programmers who have worked with gettext in C before, which uses
_("some message"), directly apply what they already know. [mc ..], on
the other hand, would be a tcl-only function name which doesn't give
too much of a hint of what this function does, except for those
programmers who happen to know that tcl's translation is done by a
package called msgcat. One might rather consider something like [tr
...], for "translate", or even [i18n ...].
That being said, I'm rather agnostic on which proc name you really
prefer. Just pick one.
Being a newcomer on this list, could you please explain to me how to
proceed with the i18n patches so far? Do you want to have patches
submitted after some further changes (which ones?) and/or in different
formats? Do you prefer to have all changes in a smaller number of
commit rather than split the way I did before? Should I wait for some
more days/weeks/whatever until you or particular other developers have
reviewed the patches? Thanks.
Christian
^ permalink raw reply
* Re: [PATCH] Internationalization of git-gui
From: Christian Stimming @ 2007-07-20 9:03 UTC (permalink / raw)
To: Brett Schwarz; +Cc: git, Paul Mackerras, Shawn O. Pearce
In-Reply-To: <622391.43998.qm@web38909.mail.mud.yahoo.com>
Quoting Brett Schwarz <brett_schwarz@yahoo.com>:
> Also, if the message catalogs are in a common location, then it
> might be worth looking into having gitk utilize these msg catalogs
> as well.
You mean you suggest to re-use existing msg catalogs in addition to
ones that are created on our own? Well, from the i18n coordination
work in another project (gnucash) I wouldn't expect any noticable
benefit from doing so. The re-usable parts of translations are rather
limited, basically limited to the standard menu entries and some more
single-word strings (Yes/No/Cancel...). But even then re-using other
translations might already decrease the quality of your own
translation, because other translators of packages might already have
chosen a different translation for e.g. "Cancel". For that reason I
strongly suggest using one single msg catalog for one single project,
so that the translator is even able to make sure each word is
translated into the same translation throughout the project.
(I also strongly suggest creating and translating a glossary of the
important terms before starting to translate the msg catalog itself,
but that's a different issue.)
> p.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able
> to convert -text and -label switches to use msgcat...it might be
> worth looking into, instead of manually editing git-gui/gitk
Thanks for the pointer. However, the -text and -label switches can be
found and edited rather easily by keyboard macros and such. More
important than this are some changes that are necessary in order to
obtain strings that are actually translatable, such as
- .mbar.apple add command -label "About [appname]" \
+ .mbar.apple add command -label [format [_ "About %s"] [appname]] \
and you will agree those can only be done manually anyway.
Christian
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-20 10:54 UTC (permalink / raw)
To: git
In-Reply-To: <200707201220.15114.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Friday 20 July 2007, David Kastrup wrote:
>> Johan Herland <johan@herland.net> writes:
>> > Sorry for jumping in late...
>>
>> It could have given you a chance to read up on what has already been
>> discussed.
>
> I have tried to keep on top of the discussion so far.
>
>> > Why do you want to add _all_ directories, and not just the ones we
>> > want to explicitly track (independent of whether they're empty or
>> > not).
>>
>> Because the problematic cases are more often than not the
>> _implicit_ cases. Do you check a directory tree for empty
>> directories before you archive it? In order to archive every empty
>> directory explicitly?
>
> No, of course I don't. But then archiving (as in tar) is intended to
> recreate the "working copy" exactly as it was. Git (and other SCMs),
> however, is only interested in recreating the part of the working
> copy it explicitly tracks.
Yes, and
git-add some-dir
tells it to track _everything_ inside some-dir. Which means that the
included files are tracked _implicitly_. The included directories
(including some-dir itself) are not.
> Given the following working copy:
> /
> /tracked/
> /tracked/file
> /tracked/dir/
> /untracked/
> /untracked/file
> /untracked/dir/
>
> and the following commands:
> $ git add tracked
>
> $ git clone
>
> The cloned result could be any of the following:
>
> (1)
> /
> /tracked/
> /tracked/file
>
> This is the current behaviour; directories are not tracked at all, but only
> added as necessary to support files.
And so your case (1) actually rather is a single line:
/tracked/file
Everything else is just part of representing /tracked/file and
disappears as soon as /tracked/file disappears.
> (2)
> /
> /tracked/
> /tracked/file
> /tracked/dir/
> /untracked/
> /untracked/dir/
>
> i.e. implicitly tracking _all_ directories. This is what you literally ask
> for,
I don't see how you can possibly conclude that from what I have been
writing.
> but I think most would find this unreasonable.
And it is. So please _don't_ put words into my mouth. In my
proposal, the following (and nothing else) would get tracked:
/tracked/.
/tracked/file
and that's it. That is what was requested, and that is what is
tracked. There will be, incidentally, a tree "/tracked/" and a tree
"/" in the _repository_, but those collapse as soon as they are empty.
They are just an _abstract_ data structuring tool in the repository
that is _mapped_ to directories on checkout.
> /
> /tracked/
> /tracked/file
> /tracked/dir/
>
> i.e. recursively tracking directories (and files). This seems useful, but
> there is nothing _implicit_ about this.
You did not ask for "/tracked/file" and you did not ask for
"/tracked/dir/" (whatever they may be). That you wanted to track them
was _implied_ by your request of "/tracked/".
> I have a feeling that you're actually arguing for doing (3) by
> default. What I am arguing is to do (1) by default, and (3) if
> given a suitable command-line option (i.e. "git add --with-dirs
> tracked").
>
> Note that this is really an interface question.
Not at all. It is a _conceptual_ question: in order for this to work
at _all_ (instead of being an inconsistent heap of ugly surprises),
directories need a representation in the repo. This representation,
as opposed to in the work file system, is _optional_: the repository
got perfectly well along without it up to now, and the fallback is
already implemented when there is a tree without corresponding
directory.
> How these entries are actually stored in the repo is a different
> discussion.
Sure. But anything that requires four dozens of special cases instead
of four because one wanted to keep "things that are under some
specialized view separate separate" is not something I am going to
implement. I am too old to juggle with complexity for the sake of
complexity. I can make much more use of the existing infrastructure
by actually making file and directory entries quite similar.
ls -la
also has no special cases for "." and ".." because they are, at a very
fundamental level, very special in achieving a special purpose
_without_ being special-cased.
> Finally, let's look at the case of "git add tracked/file" followed
> by "git rm tracked/file". I'm arguing that "tracked/" should be
> automatically removed, since I never asked for it to be tracked by
> git.
Sure. And nobody ever said otherwise. In fact, I gave about a dozen
examples in that line and more special in the thread up to now.
> On the other hand, "git-add --non-recursive tracked" followed by the
> above two commands, should of course leave "tracked/" in place,
> since I now actually asked explicitly for the directory to be
> tracked.
Sure. Use "--directory" instead of "--non-recursive" and you have a
somewhat more special option for that.
> My point is fundamentally that selectively tracking directories is a
> more powerful concept than just tracking _all_ directories by
> default.
Perhaps you might read up on some of the past discussion before
beating dead horses. This has been covered already, and more than
once. I never asked for "all directories" to be tracked. I outlined
cases where they are tracked and where not, and I tested that the
mechanisms in "man gitignore" already work _perfectly_ with the
pattern "." for configuring the _implied_ tracking at directory,
repository, project, and user preference level.
> Note that if we support selectively tracking directories, tracking
> _everything_ (like you seem to want) is trivially implemented by
> _always_ supplying the appropriate option to git-add. If we track
> everything by design, we don't have the option of selectively
> tracking some directories.
But that means manual intervention all of the time. It is fine when a
tool provides an option to shoot you in the arm instead of in the foot
as usual, but that's not really a fix, but an acerbation of the
problem.
>> > Basically, add a "--dir" flag to git-add, git-rm and friends, to
>> > tell them you're acting on the directory itself (rather than its
>> > (recursive) contents). "git-add --dir foo" will add the "040000
>> > 123abc... 0 foo" to the index/tree whether or not foo is an empty
>> > directory. "git-rm --dir foo" will remove that entry (or fail if
>> > it doesn't exist), but _not_ the contents of foo.
>>
>> There is nothing wrong with implementing something like this in
>> _addition_ to treating directory entries implicitly.
>
> I don't agree. By _selectively_ tracking directories you can
> implement any policy you want on top of it.
No, you can't. Because a "policy" means that things are _implied_.
Being able to do everything manually is not a policy. It may be a
lifesaver at times, but then you have little business drifting in the
river in the first place.
>> But the important, the _really_ important thing are the implicit
>> behaviors. If I have to hassle with every directory myself, I
>> don't need a content tracking system.
>
> I disagree. Just as you have to decide which files to track, you
>similarly should have to decide which directories to track. Of
>course, the tools make this easier for you by being able to
>recursively handle files. In the same way they should be able to do
>the same thing for directories.
--directory _explicitly_ is not working recursively, so it does not
solve that problem.
--
David Kastrup
^ permalink raw reply
* Re: GSoC status report
From: Johannes Schindelin @ 2007-07-20 10:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200707201024.35605.jnareb@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2384 bytes --]
Hi,
On Fri, 20 Jul 2007, Jakub Narebski wrote:
> How it goes with Google Summer of Code git projects:
> builtinification, libification and GitTorrent?
For my part, I am very pleased with the progress Carlos is making with
builtinification. He is quite familiar with the source code by now, and
with the style We Do Things Here(tm). Even though _he_ thinks the
progress is slow, I do not. The first phase was to get acquainted with
the code, and with the techniques to convert shell code into C.
And since Kristian joined into the builtinification process, and since
Carlos and Kristian are working together quite nicely, I am even more
happy.
FWIW this is the list of scripts that I would like to see converted by the
end of the year (feel free to object), ordered by their size:
verify-tag, reset, repack, tag, checkout, rebase, bisect,
rebase--interactive, am, commit.
It looks like 'tag' and 'commit' are pretty near to completion, with 'tag'
already being in the 'next' branch, and verify-tag will probably follow
soon.
The list left out two clusters: 'fetch' related scripts (pull, ls-remote,
parse-remote, fetch, clone) and 'merge' related scripts (merge-ours,
merge-resolve, merge-stupid, merge-octopus, merge)¹.
Julian and Daniel are working on the fetch front, and the progress is
awesome. I especially like the abstraction we have now, so that new
transports are much easier to implement. I am even tempted to have a go
at 'pushing' to bundles.
Seems like I got the 4 people I wished for the builtin project, in a way
;-)
IMHO 'stash', 'submodule' and 'filter-branch'² are not yet ready to be
made builtin.
As for the merge stuff, I consider it too soon, too, especially since
"git-merge" is a critical part of core Git _and_ quite long (even if the
same arguments would apply to 'commit', too, but Kristian is already at
work ;-)
Ciao,
Dscho
Footnote 1: I left out merge-one-file, since I have an (untested) builtin
in my tree. So there is not really much work to do there, I only have to
find some time to research how to test this script properly.
Footnote 2: Sven is working on rewrite-commits, which is somewhat more
limited than filter-branch ATM, though faster. As Junio suggested, we can
always consider using rewrite-commits as a fast backend to filter-branch,
once both rewrite-commits and filter-branch stabilised.
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Junio C Hamano @ 2007-07-20 10:34 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: David Kastrup, git
In-Reply-To: <46A08006.4020500@fs.ei.tum.de>
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:
> You are mistaking things. Like the executable bit on a file
> is not content, the fact that a directory should be kept
> despite being empty is also an *attribute* of the directory.
> This is meta-data, not actual data (content). So no matter
> how elegant tracking the "." entry might be (and I think it
> is, because it covers a lot of corner cases already), it puts
> the information at the wrong place.
Actually, I do not think there is absolute right or wrong here.
The difference is not that the information is at the "right" or
"wrong" place, but one approach places the information at more
efficient-to-use place than the other. In that sense, the
attribute approach _is_ a more elegant solution between the two.
Making it an attribute has a huge practical advantage.
By treating executable bit as a piece metadata, we can compare
the "contents" quickly. If you "chmod +x" a blob without
changing anything else, we can detect that fact, because blob
object names are equal. At the philosophical level, you _could_
argue that the executable-ness is one bit of content and include
that in the object name computation for the blob. There is
nothing fundamentally wrong about that approach, but that
destroys the nice "cheap comparability" between blobs that
differ only by executable-ness.
David's "." in tree is essentially the same argument as treating
the executable-ness as one extra bit of content. The fact that
a particular tree wants to stay even after emptied can be
treated as part of contents (thereby reflected in its object
name). There is nothing fundamentally wrong there, either. But
that means two trees that contain otherwise identical set of
blobs and subtrees, but differ only in the behaviour of when
they are emptied, would get different object names, hence you
need to descend into them to see if they are different.
Using attribute that is detached from the content itself allows
you to hoist that one bit one level up. By treating
executable-ness not as part of content, we can compare two blobs
with different executable bits cheaply. You can avoid
descending into such a tree when comparing it with another tree
that is different only by the "will-stay-when-emptied"-ness the
same way.
^ permalink raw reply
* Re: Empty directories...
From: Johan Herland @ 2007-07-20 10:20 UTC (permalink / raw)
To: git; +Cc: David Kastrup
In-Reply-To: <86hcnzxy9a.fsf@lola.quinscape.zz>
On Friday 20 July 2007, David Kastrup wrote:
> Johan Herland <johan@herland.net> writes:
> > Sorry for jumping in late...
>
> It could have given you a chance to read up on what has already been
> discussed.
I have tried to keep on top of the discussion so far.
> > Why do you want to add _all_ directories, and not just the ones we
> > want to explicitly track (independent of whether they're empty or
> > not).
>
> Because the problematic cases are more often than not the _implicit_
> cases. Do you check a directory tree for empty directories before you
> archive it? In order to archive every empty directory explicitly?
No, of course I don't. But then archiving (as in tar) is intended to recreate
the "working copy" exactly as it was. Git (and other SCMs), however, is only
interested in recreating the part of the working copy it explicitly tracks.
Given the following working copy:
/
/tracked/
/tracked/file
/tracked/dir/
/untracked/
/untracked/file
/untracked/dir/
and the following commands:
$ git add tracked
$ git clone
The cloned result could be any of the following:
(1)
/
/tracked/
/tracked/file
This is the current behaviour; directories are not tracked at all, but only
added as necessary to support files.
(2)
/
/tracked/
/tracked/file
/tracked/dir/
/untracked/
/untracked/dir/
i.e. implicitly tracking _all_ directories. This is what you literally ask
for, but I think most would find this unreasonable.
(3)
/
/tracked/
/tracked/file
/tracked/dir/
i.e. recursively tracking directories (and files). This seems useful, but
there is nothing _implicit_ about this.
I have a feeling that you're actually arguing for doing (3) by default. What I
am arguing is to do (1) by default, and (3) if given a suitable command-line
option (i.e. "git add --with-dirs tracked").
Note that this is really an interface question. How these entries are actually
stored in the repo is a different discussion.
Finally, let's look at the case of "git add tracked/file" followed by "git rm
tracked/file". I'm arguing that "tracked/" should be automatically removed,
since I never asked for it to be tracked by git. On the other
hand, "git-add --non-recursive tracked" followed by the above two commands,
should of course leave "tracked/" in place, since I now actually asked
explicitly for the directory to be tracked.
My point is fundamentally that selectively tracking directories is a more
powerful concept than just tracking _all_ directories by default. Note that
if we support selectively tracking directories, tracking _everything_ (like
you seem to want) is trivially implemented by _always_ supplying the
appropriate option to git-add. If we track everything by design, we don't
have the option of selectively tracking some directories.
> > Basically, add a "--dir" flag to git-add, git-rm and friends, to
> > tell them you're acting on the directory itself (rather than its
> > (recursive) contents). "git-add --dir foo" will add the "040000
> > 123abc... 0 foo" to the index/tree whether or not foo is an empty
> > directory. "git-rm --dir foo" will remove that entry (or fail if it
> > doesn't exist), but _not_ the contents of foo.
>
> There is nothing wrong with implementing something like this in
> _addition_ to treating directory entries implicitly.
I don't agree. By _selectively_ tracking directories you can implement any
policy you want on top of it.
> For example, ls
> has an option -d which does just that, and even git-ls-files has an
> option --directory. Heck, I even have
Yes, having commandline options for explicitly specifying directories (and not
their contents) is _exactly_ what I want.
> But the important, the _really_ important thing are the implicit
> behaviors. If I have to hassle with every directory myself, I don't
> need a content tracking system.
I disagree. Just as you have to decide which files to track, you similarly
should have to decide which directories to track. Of course, the tools make
this easier for you by being able to recursively handle files. In the same
way they should be able to do the same thing for directories.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC PATCH] Re: Empty directories...
From: Olivier Galibert @ 2007-07-20 10:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Brian Gernhardt, David Kastrup, Shawn O.Pearce,
Matthieu Moy, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0707191706120.27249@woody.linux-foundation.org>
On Thu, Jul 19, 2007 at 05:15:28PM -0700, Linus Torvalds wrote:
> (*) And, for anybody confused about the issue, the answer to the latter
> question is an emphatic: "Yes it should, live with it, and if you want the
> directory back, you had better add it back as an empty directory"
Wouldn't it be perfectly reasonable for git rm to re-add emptied
directories as empty transparently if the appropriate
flag/configuration is set? rm is porcelain after all.
OG.
^ permalink raw reply
* Re: [PATCH] Make git tag a builtin.
From: Johannes Schindelin @ 2007-07-20 10:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Rica, git
In-Reply-To: <7v1wf3zbhj.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 20 Jul 2007, Junio C Hamano wrote:
> Carlos Rica <jasampler@gmail.com> writes:
>
> > This replaces the script "git-tag.sh" with "builtin-tag.c".
>
> Thanks. Will queue in 'next', and perhaps with a few nit fixups
> to merge as the first thing after 1.5.3.
Nice!
> launch-editor() would need adjustment for GIT_EDITOR and core.editor
> which should be straightforward.
Yes. As a separate commit? After a couple of revisions, I lost track of
what I looked at, and what not... So it would make it easier for me to
have these changes after the big builtin-tag commit.
> > + sp = buf = read_sha1_file(sha1, &type, &size);
> > + if (!buf || !size)
> > + return 0;
>
> Theoretically, I can create millions of lightweight tags, all of
> them pointing at a zero-length blob object (or an empty tree
> object) and kill you with memory leak here ;-).
Yes ;-) Would we really want to say
if (!buf)
return 0;
if (!size) {
free(buf);
return 0;
}
here? IMHO that is overkill.
> > + /* skip header */
> > + while (sp + 1 < buf + size &&
> > + !(sp[0] == '\n' && sp[1] == '\n'))
> > + sp++;
> > + /* only take up to "lines" lines, and strip the signature */
> > + for (i = 0, sp += 2; i < filter->lines && sp < buf + size &&
> > + prefixcmp(sp, PGP_SIGNATURE "\n");
> > + i++) {
>
> Minor nit; I would have split this to four physical lines, like:
>
> for (i = 0, sp += 2;
> i < filter->lines && sp < buf + size &&
> prefixcmp(sp, PGP_SIGNATURE "\n");
> i++) {
>
> The places that semicolons appear are more significant gaps when
> reading the code.
I am to blame for that. That code was outlined by me.
> > +int cmd_tag(int argc, const char **argv, const char *prefix)
> > +{
> > ...
> > + if (!strcmp(arg, "-F")) {
> > + unsigned long len;
> > + int fd;
> > +
> > + annotate = 1;
> > + i++;
> > + if (i == argc)
> > + die("option -F needs an argument.");
> > +
> > + if (!strcmp(argv[i], "-"))
> > + fd = 0;
> > + else {
> > + fd = open(argv[i], O_RDONLY);
> > + if (fd < 0)
> > + die("could not open '%s': %s",
> > + argv[i], strerror(errno));
> > + }
> > + len = 1024;
> > + message = xmalloc(len);
>
> You cannot anticipate how many bytes the user will type (or
> pipe-in), but when you opened the file you could fstat() to see
> how many bytes you would need to hold the contents of that
> file. Even in stdin case fstat(fd) could tell you the size, but
> I am not sure how to tell if the st_size is reliable. But for
> the purposes of "git tag", 1k buffer that grows on demand is
> probably cheaper than a fstat() syscall.
For a one-shot program as git-tag, I agree, the current patch is
sufficient.
Ciao,
Dscho
^ 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