* Re: LCA2006 Git/Cogito tutorial
From: Horst von Brand @ 2005-10-24 0:22 UTC (permalink / raw)
To: Petr Baudis
Cc: Horst von Brand, Martin Langhoff (CatalystIT), Dmitry Torokhov,
git
In-Reply-To: <20051023224022.GX30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Sun, Oct 23, 2005 at 05:33:43PM CEST, I got a letter
> where Horst von Brand <vonbrand@inf.utfsm.cl> told me that...
> > Martin Langhoff (CatalystIT) <martin@catalyst.net.nz> wrote:
> > [...]
> > > MERGE ERROR: : Not handling case -> ->
> > It happens when a new file with the same name appears in both parents. For
> > example, we both see the need for a README file, and then I pull from you
> > and try to merge into my version.
> It certainly shouldn't happen with precisely that error message - there
> should be at least something written between the arrows.
It does now.
> And yes, there
> are unhandled cases like that, as I wrote in one of my other mails.
Yep, thanks!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: gitweb: charset problem
From: Horst von Brand @ 2005-10-24 13:56 UTC (permalink / raw)
To: Nico -telmich- Schottelius
Cc: Kay Sievers, Git Mailing List, Christian Gierke, Peter Portmann
In-Reply-To: <20051024071839.GB4608@schottelius.org>
Nico -telmich- Schottelius <nico-linux-git@schottelius.org> wrote:
> gitweb (my $version = "247";) seems to send utf-8 as meta tag encoding
> (<meta http-equiv="content-type" content="text/html; charset=utf-8"/>).
> The problem is that the name of the user "HansjOErg" (OE is the german
> umlaut) is in iso8859-1 in /etc/passwd. This is guessed, but it does not
> look like utf-8, as it's a one byte encoding:
> 00007b0: 3031 323a 3130 303a 4861 6e73 6af6 7267 012:100:Hansj.rg
> What would be the correct way to fix that? Change the username to utf-8?
> (Is this possible without causing problems in other programs?)
> Or tell gitweb that it should convert non-UTF-8 to UTF-8?
I'd be /very/ wary of usernames that aren't plain ASCII, just lovercase
letters and digits, not starting with a digit, at most 8 characters long.
I've seen more than enough hard-to-debug funnies in the most surprising
places otherwise.
> But we also have another problem: Sometimes we have umlauts in the commit
> messages. Those are also displayed incorrectly. When I switch to
> iso-8859-1 encoding in mozilla, the characters in the username and in the
> commit message are ok.
I believe the Emperor Penguin decreed messages have to be ASCII, or else
UTF-8. Please don't add to the mess by using non-portable encodings!
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Matthias Urlichs @ 2005-10-24 14:03 UTC (permalink / raw)
To: git
In-Reply-To: <7v64rnsd83.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> Maybe something like this would help?
I agree that this change, though intrusive, is a good idea.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The thing I like best about Spider-Man is that there's a hyphen in the
title. -- SJM's review of the movie
^ permalink raw reply
* Re: LCA2006 Git/Cogito tutorial
From: Linus Torvalds @ 2005-10-24 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Martin Langhoff (CatalystIT), git
In-Reply-To: <20051024075431.GY30889@pasky.or.cz>
On Mon, 24 Oct 2005, Petr Baudis wrote:
> >
> > Why? Because if you want to be slow and careful, you can always just
> > create the weave after-the-fact and do a weave merge.
>
> This doesn't make sense. Those silly weave merges only describe what to
> do with the weave to do the merge, not how you got the weave in the
> first place.
Do you think a weave is something magical that happens because the SCM
keeps the files as a weave?
No.
The weave is _not_ a "a priori" thing. The only primary thing is the
history of the file contents. Even a weave-based system will always create
the weave out of the history - it just happens to also save the file in
that woven format.
So if you have the history, you can always just re-create the weave. It's
not rocket science. SCCS has been around for how many decades now?
And the thing is, because git does NOT keep the files in weave format, it
can do the _normal_ case of a merge (same contents, never mind how they
get there) much faster than anything else. The same-file merges are so
unusual as to be unimportant - if it then takes a bit longer to handle
them because you want to use a weave, hey, you're still ahead.
> The *primary* reason for new merge strategies is not reducing number
> of conflicts, but actually being able to force a conflict at places
> where it isn't crystal-clear what the resolution should be (but not
> conflicting where it should be clear), and especially at places where
> the three-way merge *silently* gets it *wrong* without throwing any
> conflicts. And weren't it you who wanted a conservative merge strategy
> which wouldn't ever do that?
A three-way merge is plenty conservative for me.
Any merge will always get some case wrong, exactly the same way any merge
will always get some that require fixing up, even if a human might say
"that's a stupid merge". Two patches add the same thing to different
places (an unsorted array of PCI ID's or whatever), and pretty much any
merge ever will silently "mismerge" it as far as a human is concerned.
From a _technical_ point it was correct. In practice, it wasn't.
So when I say "conservative", I don't mean "can never mis-merge", because
such a thing doesn't exist. No, "conservative" means that it seldom does
it in practice, and that when it happens, you can at least understand why
it happened.
A simple strategy that makes people understand what happened is often much
better than a more complex one. And you should never underestimate the
importance of peoples _expectations_. A three-way merge has a _huge_
advantage in that absolutely tons of people are used to what it does: even
when they don't necessarily "understand" the merge (they never cared), if
they've worked with CVS they've seen them before.
Don't get me wrong - a weave merge is pretty damn conservative too. I'm
not down on weave merges, I just don't think that the difference is that
huge in practice - the difference between a three-way merge and a weave
merge is much smaller than the advantage of a good graphical tool and a
good workflow.
That's really my argument here: automated merges aren't the end-all. I
realize that a lot of SCM people think that three-way merges are old and
boring and stupid, but the fact is, sometimes the old ways aren't the best
ways, but sometimes they are old just because they are good enough.
Linus
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Linus Torvalds @ 2005-10-24 16:02 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867jc336f4.fsf@blue.stonehenge.com>
On Sun, 23 Oct 2005, Randal L. Schwartz wrote:
>
> If that rings a bell, help me out here. I'm guessing "isalnum" is getting
> defined (wrongly). Yeah, looks like in cache.h. Why is this getting
> defined?
We're doing our own ctype.h.
The fix is to make sure that "cache.h" is included _after_ system
includes.
iow, this should fix it, methinks.
Linus
---
diff --git a/daemon.c b/daemon.c
index 0c6182f..6e5de11 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,5 +1,3 @@
-#include "cache.h"
-#include "pkt-line.h"
#include <signal.h>
#include <sys/wait.h>
#include <sys/socket.h>
@@ -10,6 +8,9 @@
#include <arpa/inet.h>
#include <syslog.h>
+#include "cache.h"
+#include "pkt-line.h"
+
static int log_syslog;
static int verbose;
^ permalink raw reply related
* Re: daemon.c broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-24 16:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510240901020.10477@g5.osdl.org>
>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
Linus> We're doing our own ctype.h.
Linus> The fix is to make sure that "cache.h" is included _after_ system
Linus> includes.
That probably won't work, because on OpenBSD, it's not a #define, but
rather a real function call. You can't just #undef that (unless my C
is even more rusty).
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: "Racy" GIT
From: Linus Torvalds @ 2005-10-24 16:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051024092952.GZ30889@pasky.or.cz>
On Mon, 24 Oct 2005, Petr Baudis wrote:
>
> Guess what - the second cg-commit didn't commit the new version of the
> file. git-diff-index didn't show anything. GIT just didn't care about
> the change.
Yeah. This is why I wanted to use the "tv_nsec" field originally.
As it is, if you change a file within a second so that the length is the
same (and inode stays the same), the stat cache can't help you.
Now, this will only trigger if you do a git-update-index (either directly
or like in your example, indirectly though doing a commit that does it)
and then change it again immediately, so in practice it shouldn't matter.
Except for scripts.
In scripts, you can avoid this certain ways:
- add a "sleep 1" (gaah, just joking, but it works)
- use "git-apply --index" (which updates the index on its own on any
files it changes) to apply any patches.
- use an explicit "git-update-index -- filename"
- if you actually change the inode number, it should be ok, ie
sed script < a > b && mv b a
will change the inode number, and that should trigger the index tests
too. NOTE!! This isn't guaranteed, especially if you do it twice (it
might re-use the original one)
Note that "git-update-index --refresh" will _not_ work, since it looks if
it changed. But an explicit filename will force an update if you know it
changed.
And yes, I guess we should document this in big letters.
(There _are_ actually tricks you can do to make this usually less of an
issue:
- if the git-update-cache --refresh finds file where the mtime matches
the current date. It sets a flag. At the end, it waits for the next
second to roll around before returning.
might work well enough)
Linus
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Linus Torvalds @ 2005-10-24 16:43 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86irvmzyq9.fsf@blue.stonehenge.com>
On Mon, 24 Oct 2005, Randal L. Schwartz wrote:
>
> That probably won't work, because on OpenBSD, it's not a #define, but
> rather a real function call. You can't just #undef that (unless my C
> is even more rusty).
Sure you can.
The #undef won't necessarily _do_ anything, but it protects against
systems where it is a #define. Then, the #define makes sure that if it's
anything else, the #define will take precedence.
So yes, it's ugly, but it definitely is safe in practice, as long as the
local headers are included before the system ones.
I think Junio's patch (that renames things) is possibly the "cleaner"
alternative, but on the other hand there's a lot of advantages to just
using the standard names. No chance of somebody using the wrong version by
mistake.
Linus
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: H. Peter Anvin @ 2005-10-24 17:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0510240936450.10477@g5.osdl.org>
Linus Torvalds wrote:
>
> I think Junio's patch (that renames things) is possibly the "cleaner"
> alternative, but on the other hand there's a lot of advantages to just
> using the standard names. No chance of somebody using the wrong version by
> mistake.
>
But there is also no risk of other unexpected dependencies. I would
vote for using git-specific names.
-hpa
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Linus Torvalds @ 2005-10-24 17:14 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510240936450.10477@g5.osdl.org>
On Mon, 24 Oct 2005, Linus Torvalds wrote:
>
> So yes, it's ugly, but it definitely is safe in practice, as long as the
> local headers are included before the system ones.
Side note: "safe in practice" isn't necessarily the same as "safe in
theory".
I think that strictly speaking, if you include <ctype.h>, the "isxxxx()"
format is always reserved (where "x" is lowercase letters), and in theory
you could have a compiler that recognizes them even before the
pre-processor as being something built-in.
In _practice_, such a compiler would be incredibly broken (it would have
to do the recognition after preprocessing too), and I doubt you'd ever see
such a thing, but from a pure language-lawyer standpoint it might
technically be possible.
However, I'm surprised that you see <ctype.h> at all. The OpenBSD headers
seem to be including <ctype.h> from <sys/poll.h>, which doesn't make any
sense. It may not be strictly against POSIX, but it's definitely strange
and bad form to do unnecessary name pollution that the user didn't ask
for.
So git actually tries to be pretty good about things. Not only does it try
to handle any existing system <ctype.h> by doing the #undef, it actually
doesn't include the system ctype.h at _all_ when it includes "cache.h".
And OpenBSD is being a bit strange.
Linus
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: H. Peter Anvin @ 2005-10-24 17:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0510241002180.10477@g5.osdl.org>
Linus Torvalds wrote:
>
> Side note: "safe in practice" isn't necessarily the same as "safe in
> theory".
>
> I think that strictly speaking, if you include <ctype.h>, the "isxxxx()"
> format is always reserved (where "x" is lowercase letters), and in theory
> you could have a compiler that recognizes them even before the
> pre-processor as being something built-in.
>
> In _practice_, such a compiler would be incredibly broken (it would have
> to do the recognition after preprocessing too), and I doubt you'd ever see
> such a thing, but from a pure language-lawyer standpoint it might
> technically be possible.
>
A much more likely cause for problems would be system headers that use
the isxxx() macros as part of other macros. That would be in violation
of POSIX, but is reasonably common.
> However, I'm surprised that you see <ctype.h> at all. The OpenBSD headers
> seem to be including <ctype.h> from <sys/poll.h>, which doesn't make any
> sense. It may not be strictly against POSIX, but it's definitely strange
> and bad form to do unnecessary name pollution that the user didn't ask
> for.
It is strictly against POSIX, but again, fairly common.
> So git actually tries to be pretty good about things. Not only does it try
> to handle any existing system <ctype.h> by doing the #undef, it actually
> doesn't include the system ctype.h at _all_ when it includes "cache.h".
> And OpenBSD is being a bit strange.
I think there is another good reason for doing the renaming bit: we're
creating new macros with different semantics; in particular, the git
macros handle signed char input and don't guarantee anything w.r.t. EOF.
-hpa
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Linus Torvalds @ 2005-10-24 17:58 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Randal L. Schwartz, git
In-Reply-To: <435D1963.8070205@zytor.com>
On Mon, 24 Oct 2005, H. Peter Anvin wrote:
>
> A much more likely cause for problems would be system headers that use the
> isxxx() macros as part of other macros. That would be in violation of POSIX,
> but is reasonably common.
Hmm.. Yes, that's a good point. I don't see what thing could do it that we
care about (and since we do actually do a pretty valid ctype
implementation, it should all work out right regardless), but yes, it
might be safer to rename the things.
Especially if we then continue to make sure _not_ to include <ctype.h>
ourselves, so that only systems with broken headers (like the ones on
OpenBSD ;) could ever use the standard names anyway. That way we'd not
have to worry whether somebody uses them by mistake..
Btw, nobody ever replied to my question whether we might be using
something else that is locale-specific. I'm not actually locate-aware
enough to even know what else than <ctype.h> might be dangerous to use..
Anybody?
Linus
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: H. Peter Anvin @ 2005-10-24 18:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0510241054480.10477@g5.osdl.org>
Linus Torvalds wrote:
>
> Btw, nobody ever replied to my question whether we might be using
> something else that is locale-specific. I'm not actually locate-aware
> enough to even know what else than <ctype.h> might be dangerous to use..
>
Regexxen are probably the single most problematic thing.
-hpa
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Morten Welinder @ 2005-10-24 18:25 UTC (permalink / raw)
To: GIT Mailing List; +Cc: Linus Torvalds
In-Reply-To: <435D21DE.6080404@zytor.com>
Locale issues:
* Environment strings have unspecified encoding.
* File names ditto. (Which matters when they get printed together with other
strings.)
* gecos information ditto.
If, and if only, you[*] call setlocale:
* ctype stuff.
* strtod, printf %[efg]
* Regexps
(Integer parsing and printing seems to be safe in pratice if not in theory.)
If you call system() you also need to watch out for things like Gnu sort
being locale sensitive.
Morten
[*] That would be not just you, but also all the yous behind all the
libraries you link.
^ permalink raw reply
* The MIT error
From: Morten Welinder @ 2005-10-24 18:57 UTC (permalink / raw)
To: GIT Mailing List
After the isspace/BSD conflict I looked into what reserved symbols are
being used by git. Quite a few, it turns out.
--M.
The C standard says you should not use identifiers matching:
(is|to)[a-z].* <-- such as isize
E[0-9A-Z].* <-- such as EMIT
str[a-z].* <-- such as strbuf
(PRI|SCN)[a-zX].*
LC_[A-Z].*
(SIG|SIG_)[A-Z].*
(uint|int).*_t
(UINT|INT).*_(MIN|MAX|C)
wcs[a-z].*
The three top ones are the easiest to violate. While fixing the existing
violations is probably pointless, new code ought not make things worse.
Just as isspace is reserved by the C implementation...
7.26.2 Character handling <ctype.h>
[#1] Function names that begin with either is or to, and a
lowercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <ctype.h> header.
[so there goes any use of "isize"], so are macro names EMIT, ETHIS,
and ETHAT, at least when <errno.h> is included.
7.26.3 Errors <errno.h>
[#1] Macros that begin with E and a digit or E and an
uppercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <errno.h> header.
quote.c:#undef EMIT
quote.c:#define EMIT(x) ( (++len < n) && (*bp++ = (x)) )
quote.c:#define EMITQ() EMIT('\\')
server-info.c:#define EMITTED 04
tar-tree.c:#define EXT_HEADER_PATH 1
tar-tree.c:#define EXT_HEADER_LINKPATH 2
ls-files.c:#define EXC_CMDL 0
ls-files.c:#define EXC_DIRS 1
ls-files.c:#define EXC_FILE 2
epoch.h:#define EPOCH_H
update-index.c:static inline void *ERR_PTR(long error)
7.26.10 General utilities <stdlib.h>
[#1] Function names that begin with str and a lowercase
letter (possibly followed by any combination of digits,
letters, and underscore) may be added to the declarations in
the <stdlib.h> header.
^ permalink raw reply
* RFE: git rm
From: Jeff Garzik @ 2005-10-24 19:02 UTC (permalink / raw)
To: Git Mailing List
It would be nice to say "git rm files..." and have two operations occur:
* list of files is passed to rm(1)
* list of files is passed to git-update-index --remove
^ permalink raw reply
* Re: RFE: git rm
From: H. Peter Anvin @ 2005-10-24 19:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <435D2FE0.3060307@pobox.com>
Jeff Garzik wrote:
>
> It would be nice to say "git rm files..." and have two operations occur:
>
> * list of files is passed to rm(1)
> * list of files is passed to git-update-index --remove
>
Install cogito and you have the above as "cg-rm".
-hpa
^ permalink raw reply
* Re: RFE: git rm
From: Junio C Hamano @ 2005-10-24 20:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <435D2FE0.3060307@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> It would be nice to say "git rm files..." and have two operations occur:
>
> * list of files is passed to rm(1)
> * list of files is passed to git-update-index --remove
This is not a big problem *if* your index always matches the
HEAD tree (i.e. no intermediate git-update-index in between
commits) --- you can just say "rm -f files..." at the point of
removal, continue your work, and either pass these files from
the command line, or -a flag when running 'git commit'.
Running git-update-index in between commits is a valid thing to
do, and it helps reducing the clutter when viewing 'git diff' to
see what your changes look like since your last update-index.
The workflow would go like this:
1$ git checkout
... work work work
... what have I done so far?
2$ git diff
... the intermediate result looks OK, so record what we have
... done so far...
3$ git-update-index --add --remove files...
... work work work
... go back to step 2 as many times as needed.
... now what is the sum of changes since the last commit?
4$ git diff HEAD
... everything looks OK. record the last bits and commit.
5$ git-update-index --add --remove files...
6$ git commit
Previously Linus stated that his index almost always matches the
HEAD tree, and I personally do not do intermediate update-index
ever myself, but I am curious how other people use git [*1*].
If some of you run update-index in between commits, "git rm
files..." would make a lot of sense.
[Footnote]
*1* Cogito users do not count -- they are supposed to leave
index file manipulation to Cogito's smart.
^ permalink raw reply
* [PATCH] cg-fetch: Fixed missing $COGITO_LIB path
From: Martin Langhoff @ 2005-10-24 20:49 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Trivial fix -- prevents cg-fetch from working on systems where the COGITO_LIB
env var isn't set.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Resend: Added signoff as requested.
---
cg-fetch | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 6dd73afff0a1f3e2433b90e2ea42f8500393bd97
ae2ea27f59cdb22d7587aaa49f12f29e1b1f77e1
diff --git a/cg-fetch b/cg-fetch
index f0c11aa..80b2a03 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -39,7 +39,7 @@ deprecated_alias cg-fetch cg-pull
fetch_progress()
{
- exec cg-Xfetchprogress "$_git_objects"
+ exec ${COGITO_LIB}cg-Xfetchprogress "$_git_objects"
}
show_changes_summary()
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] cg-fetch: handle tags with funny chars, retrieve missing commits
From: Martin Langhoff @ 2005-10-24 20:49 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
+ handles tags with funny chars a bit better
+ will check tagrefs, trying to ensure it actually has the relevant
commits. If the commits are missing, it'll go out and fetch them.
+ if the tagref points to a blob and we have it, it'll skip it
This isn't a complete solution for cg-fetch -- git-fetch is actually
much smarter now, and cg-fetch should perhaps be a thin wrapper
around it, dropping all the duplicate code.
This version uses ^0 instead of ^{commit} which does a more thorough check,
so we don't need to call git-cat-file.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Resend: added signoff as requested.
---
cg-fetch | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
applies-to: e6fab694ece986de77f6e17c16df9f17276c6666
e2cf1ab9b594d3d12655dd93377dfea03247379e
diff --git a/cg-fetch b/cg-fetch
index b004ab3..f0c11aa 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -377,7 +377,8 @@ $get -i -s -u -d "$uri/refs/tags" "$_git
for tag in *; do
[ "$tag" = "*" ] && break
tagid="$(cat "$tag")"
- GIT_DIR=../.. git-cat-file -t "$tagid" >/dev/null 2>&1 && continue
+ GIT_DIR=../.. git-rev-parse --verify "$tag"^0 2>/dev/null >> /dev/null && continue
+ GIT_DIR=../.. git-cat-file blob `git-rev-parse --verify "$tag"^{blob} 2>/dev/null` 2>/dev/null >> /dev/null && continue
echo -n "Missing object of tag $tag... "
if [ "$fetch" != "fetch_rsync" ] && GIT_DIR=../.. $fetch "$tagid" "$uri" 2>/dev/null >&2; then
echo "retrieved"
---
0.99.8.GIT
^ permalink raw reply related
* Re: daemon.c broken on OpenBSD
From: Junio C Hamano @ 2005-10-24 20:59 UTC (permalink / raw)
To: H. Peter Anvin, Randal L. Schwartz; +Cc: git
In-Reply-To: <435D1963.8070205@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> I think there is another good reason for doing the renaming bit: we're
> creating new macros with different semantics; in particular, the git
> macros handle signed char input and don't guarantee anything w.r.t. EOF.
>
> -hpa
Thanks. I'll include the renaming bits to "master" branch when
I hear somebody on OpenBSD confirms that the patch fixes it.
^ permalink raw reply
* Re: [PATCH] cg-fetch: Fixed missing $COGITO_LIB path
From: Junio C Hamano @ 2005-10-24 21:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11301869531376-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> fetch_progress()
> {
> - exec cg-Xfetchprogress "$_git_objects"
> + exec ${COGITO_LIB}cg-Xfetchprogress "$_git_objects"
> }
I think somebody recently sent a patch to quote the variable so
that you can have whitespace in it. So probably:
exec "${COGITO_LIB}"cg-Xfetchprogress "$_git_objects"
or even "${COGITO_LIB}/"cg-...
^ permalink raw reply
* Re: RFE: git rm
From: Daniel Barkalow @ 2005-10-24 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff Garzik, git
In-Reply-To: <7virvmodhz.fsf@assigned-by-dhcp.cox.net>
On Mon, 24 Oct 2005, Junio C Hamano wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>
> > It would be nice to say "git rm files..." and have two operations occur:
> >
> > * list of files is passed to rm(1)
> > * list of files is passed to git-update-index --remove
>
> This is not a big problem *if* your index always matches the
> HEAD tree (i.e. no intermediate git-update-index in between
> commits) --- you can just say "rm -f files..." at the point of
> removal, continue your work, and either pass these files from
> the command line, or -a flag when running 'git commit'.
>
> Running git-update-index in between commits is a valid thing to
> do, and it helps reducing the clutter when viewing 'git diff' to
> see what your changes look like since your last update-index.
> The workflow would go like this:
>
> 1$ git checkout
> ... work work work
>
> ... what have I done so far?
> 2$ git diff
> ... the intermediate result looks OK, so record what we have
> ... done so far...
> 3$ git-update-index --add --remove files...
>
> ... work work work
> ... go back to step 2 as many times as needed.
>
> ... now what is the sum of changes since the last commit?
> 4$ git diff HEAD
>
> ... everything looks OK. record the last bits and commit.
> 5$ git-update-index --add --remove files...
> 6$ git commit
>
> Previously Linus stated that his index almost always matches the
> HEAD tree, and I personally do not do intermediate update-index
> ever myself, but I am curious how other people use git [*1*].
> If some of you run update-index in between commits, "git rm
> files..." would make a lot of sense.
I often do "git add something" when I happen to think of it, not
necessarily right before committing, which means that I have these files
changed in my index while working. I may quit this, however, now that git
status lists the ones I missed.
Incidentally, the new git status entry for --others really ought to say
something different from "Ignored files", like "Exist but not tracked",
since it doesn't include the contents of .gitignore, which you'd expect to
be "Ignored". (And, of course, any files it lists are hardly being
ignored.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: gitweb: charset problem
From: Daniel Barkalow @ 2005-10-24 21:55 UTC (permalink / raw)
To: Horst von Brand
Cc: Nico -telmich- Schottelius, Kay Sievers, Git Mailing List,
Christian Gierke, Peter Portmann, Junio C Hamano
In-Reply-To: <200510241356.j9ODuAHn005060@laptop11.inf.utfsm.cl>
On Mon, 24 Oct 2005, Horst von Brand wrote:
> > But we also have another problem: Sometimes we have umlauts in the commit
> > messages. Those are also displayed incorrectly. When I switch to
> > iso-8859-1 encoding in mozilla, the characters in the username and in the
> > commit message are ok.
>
> I believe the Emperor Penguin decreed messages have to be ASCII, or else
> UTF-8. Please don't add to the mess by using non-portable encodings!
Should we possibly reject non-UTF-8 input to commits?
IIRC, we actually define that to be UTF-8, unlike most of the other stuff,
for which we don't actually insist on a policy.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: RFE: git rm
From: Junio C Hamano @ 2005-10-24 22:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510241725370.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I often do "git add something" when I happen to think of it, not
> necessarily right before committing, which means that I have these files
> changed in my index while working. I may quit this, however, now that git
> status lists the ones I missed.
Oh, I do 'git add' myself; otherwise I'd surely forget by the
time I commit.
And I did not mean to tell you to quit doing it. If any of you
took what I said as "Linus does not do it, I do not do it, so
you should not be doing update-index in the middle", then that
was not my intention and I apologize for causing confusion.
I think update-index in the middle is a valid workflow. The
only drawback I can think of is that you cannot merge or apply
others' patches once you do it until you commit. I was just
curious how people use git, weighing the pros and cons of that
(pros: git-diff-files is easier to read and the index gives you
a good anchoring point; cons: you cannot do merge or patch
application).
> Incidentally, the new git status entry for --others really ought to say
> something different from "Ignored files", like "Exist but not tracked",
> since it doesn't include the contents of .gitignore, which you'd expect to
> be "Ignored". (And, of course, any files it lists are hardly being
> ignored.)
Good point. Something like this?
------------
Clarify git status output.
What we list as "Ignored files" are not "ignored". Rather, it
is the list of "not listed in the to-be-ignored files, but
exists -- you may be forgetting to add them".
Pointed out by Daniel.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-status.sh b/git-status.sh
index 29c2b11..62a24a9 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -90,7 +90,7 @@ perl -e '$/ = "\0";
s|\n|\\n|g;
s/^/# /;
if (!$shown) {
- print "#\n# Ignored files:\n";
+ print "#\n# Untracked files:\n";
print "# (use \"git add\" to add to commit)\n#\n";
$shown = 1;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox