* Re: Cannot install git RPM
From: Junio C Hamano @ 2005-08-09 17:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <7v3bpjxoi1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> But the resulting RPM cannot be installed either, at least not in
>> standard Fedora Core 2/3/4 installations:
>> ...
>> Is there at least some documentation which external packages are
>> needed, and where to find these?
The problematic one is git-send-email-script.
I have to admit that it was a mistake to take that patch; I was
trying to be _too_ inclusive. The script does not even read
from nor write into a git repository, and the only relevance to
git is that it is useful for people to patchbomb the list with
git generated patches. In other words, the program may be
useful, but its usefulness does not have much to do with git, so
it does not belong to git.
My short-term plan is to downgrade it to "contrib" status, and
not touch it from the main Makefile. It will be in the 0.99.4
sources but will not be installed nor made into binary package.
I hope Ryan does not mind this decision.
After we audit the set of tools we currently ship, along with
some other scripts/programs, either we remove it altogether from
our source tree, or create a contrib/ subdirectory and move it
there.
^ permalink raw reply
* Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Junio C Hamano @ 2005-08-09 17:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0508091618320.7995@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> True. My bad old habit.
>
> An elegant method to do that:
>
> case --some-long-option in "$1"*) ..; esac
You are almost correct, but you need to realize that I generate
that long "case -s|--s|--so|--som|..." chain using a script that
takes all potential option names as its arguments, and makes
case arms that contain only unambiguous ones, so that I can
handle --some-long-option and --some-other-long-option sensibly.
Also you forgot to grok --some-option-with-args=* in your
version ;-).
^ permalink raw reply
* cg-clone http://www.kernel.org/pub/scm/git/git.git fails
From: Dirk Behme @ 2005-08-09 16:06 UTC (permalink / raw)
To: git
Hello,
with
cogito-0.13.tar.bz2
git-2005-08-09.tar.gz
clone of cogito over http
> cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git
works fine. But clone of git itself fails:
> cg-clone http://www.kernel.org/pub/scm/git/git.git
defaulting to local storage area
warning: templates not found /home/user/share/git-core/templates/
16:29:03 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master
[41/41] -> "refs/heads/origin" [1]
progress: 3 objects, 5158 bytes
Getting pack list
error: Unable to get pack index
http://www.kernel.org/pub/scm/git/git.git//objects/info/packs
error: Tried
http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
while processing commit adee7bdf504120055b0f36b4918bdd3e6156912b.
cg-pull: objects pull failed
cg-clone: pull failed
Is this a tool or repository issue?
Many thanks
Dirk
^ permalink raw reply
* Re: Cannot install git RPM
From: Clemens Koller @ 2005-08-09 15:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Wolfgang Denk, git
In-Reply-To: <Pine.LNX.4.58.0508090758110.3258@g5.osdl.org>
Hi, Linus!
Linus Torvalds wrote:
>
> On Tue, 9 Aug 2005, Clemens Koller wrote:
>
>>Over here - using a non-standard ELDK/LFS mixture, git depends at least on:
>>...
>>diffstat (ftp://invisible-island.net/diffstat/diffstat-1.39.tgz)
>
>
> Hmm.. This should not be true. Any "diffstat"s should be converted to use
> "git-apply --stat" instead.
>
> I don't find any diffstat users, so maybe you just remember it from "the
> old days", and didn't realize that it's not needed any more.
Okay, just FYI: As far as my installation history remembers it was needed
at least up to:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
Which is _NOT_ recommended for new installations!
(Can somebody please remove/mark that old stuff to avoid using it?!)
Instead use:
http://www.codemonkey.org.uk/projects/git-snapshots/git/git-latest.tar.gz
> [ That said, anybody who wants to install git might as well install
> diffstat, it's a useful program in general, and works on more than just
> unified diffs ]
true.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* [PATCH] -Werror fixes
From: Timo Sirainen @ 2005-08-09 15:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 6828 bytes --]
GCC's format __attribute__ is good for checking errors, especially with
-Werror=2 parameter. Patch below fixes most of the reported problems
against 2005-08-09 snapshot.
Also how about trying to implement some kind of generically usable
string object? Now the code uses sprintf/snprintf/etc. in various
different ways with their own memory allocations, and it looks all messy
and difficult to verify their correctness.
diff -ru git-current/apply.c git-modified/apply.c
--- git-current/apply.c 2005-08-09 18:00:06.000000000 +0300
+++ git-modified/apply.c 2005-08-09 17:50:13.712911497 +0300
@@ -563,7 +563,7 @@
struct fragment dummy;
if (parse_fragment_header(line, len, &dummy) < 0)
continue;
- error("patch fragment without header at line %d: %.*s", linenr, len-1, line);
+ error("patch fragment without header at line %d: %.*s", linenr, (int)len-1, line);
}
if (size < len + 6)
@@ -968,7 +968,7 @@
while (frag) {
if (apply_one_fragment(desc, frag) < 0)
- return error("patch failed: %s:%d", patch->old_name, frag->oldpos);
+ return error("patch failed: %s:%ld", patch->old_name, frag->oldpos);
frag = frag->next;
}
return 0;
diff -ru git-current/cache.h git-modified/cache.h
--- git-current/cache.h 2005-08-09 18:00:06.000000000 +0300
+++ git-modified/cache.h 2005-08-09 18:14:37.858158948 +0300
@@ -40,6 +40,10 @@
#define NORETURN
#endif
+#ifndef __attribute__
+#define __attribute(x)
+#endif
+
/*
* Intensive research over the course of many years has shown that
* port 9418 is totally unused by anything else. Or
@@ -171,8 +175,8 @@
#define TYPE_CHANGED 0x0040
/* Return a statically allocated filename matching the sha1 signature */
-extern char *mkpath(const char *fmt, ...);
-extern char *git_path(const char *fmt, ...);
+extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
+extern char *git_path(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern char *sha1_file_name(const unsigned char *sha1);
extern char *sha1_pack_name(const unsigned char *sha1);
extern char *sha1_pack_index_name(const unsigned char *sha1);
@@ -218,8 +222,8 @@
/* General helper functions */
extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN;
-extern int error(const char *err, ...);
+extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern int base_name_compare(const char *name1, int len1, int mode1, const char *name2, int len2, int mode2);
extern int cache_name_compare(const char *name1, int len1, const char *name2, int len2);
diff -ru git-current/clone-pack.c git-modified/clone-pack.c
--- git-current/clone-pack.c 2005-08-09 18:00:06.000000000 +0300
+++ git-modified/clone-pack.c 2005-08-09 17:53:32.295922222 +0300
@@ -30,7 +30,7 @@
static void write_one_ref(struct ref *ref)
{
- char *path = git_path(ref->name);
+ char *path = git_path("%s", ref->name);
int fd;
char *hex;
diff -ru git-current/connect.c git-modified/connect.c
--- git-current/connect.c 2005-08-09 18:00:06.000000000 +0300
+++ git-modified/connect.c 2005-08-09 17:46:35.187838763 +0300
@@ -166,7 +166,8 @@
if (matched_src)
break;
errs = 1;
- error("src refspec %s does not match any.");
+ error("src refspec %s does not match any.",
+ rs[i].src);
break;
default:
errs = 1;
diff -ru git-current/csum-file.h git-modified/csum-file.h
--- git-current/csum-file.h 2005-08-09 18:00:06.000000000 +0300
+++ git-modified/csum-file.h 2005-08-09 18:02:33.825363592 +0300
@@ -11,7 +11,7 @@
};
extern struct sha1file *sha1fd(int fd, const char *name);
-extern struct sha1file *sha1create(const char *fmt, ...);
+extern struct sha1file *sha1create(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern int sha1close(struct sha1file *, unsigned char *, int);
extern int sha1write(struct sha1file *, void *, unsigned int);
extern int sha1write_compressed(struct sha1file *, void *, unsigned int);
diff -ru git-current/pack-check.c git-modified/pack-check.c
--- git-current/pack-check.c 2005-08-09 18:00:07.000000000 +0300
+++ git-modified/pack-check.c 2005-08-09 17:46:24.084918180 +0300
@@ -15,7 +15,7 @@
/* Header consistency check */
hdr = p->pack_base;
if (hdr->hdr_signature != htonl(PACK_SIGNATURE))
- return error("Packfile signature mismatch", p->pack_name);
+ return error("Packfile %s signature mismatch", p->pack_name);
if (hdr->hdr_version != htonl(PACK_VERSION))
return error("Packfile version %d different from ours %d",
ntohl(hdr->hdr_version), PACK_VERSION);
diff -ru git-current/pkt-line.h git-modified/pkt-line.h
--- git-current/pkt-line.h 2005-08-09 18:00:07.000000000 +0300
+++ git-modified/pkt-line.h 2005-08-09 18:02:56.637125022 +0300
@@ -5,7 +5,7 @@
* Silly packetized line writing interface
*/
void packet_flush(int fd);
-void packet_write(int fd, const char *fmt, ...);
+void packet_write(int fd, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
int packet_read_line(int fd, char *buffer, unsigned size);
diff -ru git-current/refs.c git-modified/refs.c
--- git-current/refs.c 2005-08-09 18:00:07.000000000 +0300
+++ git-modified/refs.c 2005-08-09 17:53:25.318217137 +0300
@@ -6,7 +6,7 @@
static int read_ref(const char *refname, unsigned char *sha1)
{
int ret = -1;
- int fd = open(git_path(refname), O_RDONLY);
+ int fd = open(git_path("%s", refname), O_RDONLY);
if (fd >= 0) {
char buffer[60];
@@ -20,7 +20,7 @@
static int do_for_each_ref(const char *base, int (*fn)(const char *path, const unsigned char *sha1))
{
int retval = 0;
- DIR *dir = opendir(git_path(base));
+ DIR *dir = opendir(git_path("%s", base));
if (dir) {
struct dirent *de;
@@ -46,7 +46,7 @@
if (namelen > 255)
continue;
memcpy(path + baselen, de->d_name, namelen+1);
- if (lstat(git_path(path), &st) < 0)
+ if (lstat(git_path("%s", path), &st) < 0)
continue;
if (S_ISDIR(st.st_mode)) {
retval = do_for_each_ref(path, fn);
diff -ru git-current/tar-tree.c git-modified/tar-tree.c
--- git-current/tar-tree.c 2005-08-09 18:00:07.000000000 +0300
+++ git-modified/tar-tree.c 2005-08-09 17:49:27.512564400 +0300
@@ -325,8 +325,8 @@
memcpy(&header[257], "ustar", 6);
memcpy(&header[263], "00", 2);
- printf(&header[329], "%07o", 0); /* devmajor */
- printf(&header[337], "%07o", 0); /* devminor */
+ sprintf(&header[329], "%07o", 0); /* devmajor */
+ sprintf(&header[337], "%07o", 0); /* devminor */
memset(&header[148], ' ', 8);
for (i = 0; i < RECORDSIZE; i++)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cannot install git RPM
From: Linus Torvalds @ 2005-08-09 15:00 UTC (permalink / raw)
To: Clemens Koller; +Cc: Wolfgang Denk, git
In-Reply-To: <42F8AE6E.2020808@anagramm.de>
On Tue, 9 Aug 2005, Clemens Koller wrote:
>
> Over here - using a non-standard ELDK/LFS mixture, git depends at least on:
>...
> diffstat (ftp://invisible-island.net/diffstat/diffstat-1.39.tgz)
Hmm.. This should not be true. Any "diffstat"s should be converted to use
"git-apply --stat" instead.
I don't find any diffstat users, so maybe you just remember it from "the
old days", and didn't realize that it's not needed any more.
[ That said, anybody who wants to install git might as well install
diffstat, it's a useful program in general, and works on more than just
unified diffs ]
Linus
^ permalink raw reply
* Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Johannes Schindelin @ 2005-08-09 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vu0hzw9sx.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 9 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > - I don't like the GNU way to abbreviate long options too much...
>
> True. My bad old habit.
An elegant method to do that:
case --some-long-option in "$1"*) ..; esac
Ciao,
Dscho
^ permalink raw reply
* Re: Cannot install git RPM
From: Clemens Koller @ 2005-08-09 13:23 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050809110705.6B1FF352B36@atlas.denx.de>
Hello, Wolfgang!
> But the resulting RPM cannot be installed either, at least not in
> standard Fedora Core 2/3/4 installations:
>
> error: Failed dependencies:
> perl(Email::Valid) is needed by git-core-0.99.3-1
> perl(Mail::Sendmail) is needed by git-core-0.99.3-1
>
>
> Seems git is depending on more and more stuff which is not available
> in standard distros. This makes it not easier for new users...
>
> Is there at least some documentation which external packages are
> needed, and where to find these?
Over here - using a non-standard ELDK/LFS mixture, git depends at least on:
zlib ()
libcurl (http://curl.haxx.se/download/curl-7.14.0.tar.bz2)
openssl ()
diff ()
diffstat (ftp://invisible-island.net/diffstat/diffstat-1.39.tgz)
which (http://www.xs4all.nl/~carlo17/which/which-2.16.tar.gz)
rsync (http://samba.anu.edu.au/ftp/rsync/rsync-2.6.5.tar.gz)
perl ()
() -> ask Google.
The versions given in brackets seem to work fine for me. - YMMV
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Junio C Hamano @ 2005-08-09 12:56 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Pavel Roskin, git
In-Reply-To: <20050808231036.GA22778@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> I haven't really given a lot of thought to this yet, but I was thinking
> of something along these lines:
>
> Rename tools/ to mail-tools/, push git-send-email-script into that.
> Create a "porcelain" directory for things like git-bisect-script
> Create a "core" directory for things like "git-commit-script"
> Create a "src" (?) directory for *.[ch]
> Maybe move documentation into the same directory as the scripts they
> belong to.
A good place to start may be to reorganize the categorized list
of commands in Documentation/git.txt.
^ permalink raw reply
* Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Junio C Hamano @ 2005-08-09 12:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0508091212170.6752@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I just checked. Three nitpicks:
>
> - I don't like the GNU way to abbreviate long options too much...
True. My bad old habit.
> - Multiple -m options was actually a feature of my version of the patch.
Ah, OK.
> - The "case .. in x) .. ;; esac;" construct is sometimes more confusing
> than a simple "if", or even a "[ .. = x ] && ..".
Yes sometimes.
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Junio C Hamano @ 2005-08-09 12:51 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linus Torvalds, git
In-Reply-To: <tnxmznr32cy.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> If you plan to implement multiple values in FETCH_HEAD, StGIT won't be
> able to use this since it doesn't do any merging for the base of the
> stack. As I said above, this is not a problem and I was probably wrong
> when decided to use git-fetch-script directly and not git-pull-script.
>
> Please let me know if you need more info.
Thanks. Perfectly clear.
^ permalink raw reply
* Re: Cannot install git RPM
From: Junio C Hamano @ 2005-08-09 12:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: git
In-Reply-To: <20050809110705.6B1FF352B36@atlas.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> A simple fix is of course:
>
> -> diff -u git-core.spec.in.ORIG git-core.spec.in
> --- git-core.spec.in.ORIG 2005-08-09 10:26:50.845877000 +0200
> +++ git-core.spec.in 2005-08-09 12:42:06.872310918 +0200
> @@ -40,6 +40,7 @@
> %{!?_without_docs: %doc Documentation/*.html }
> %{!?_without_docs: %{_mandir}/man1/*.1.gz}
> %{!?_without_docs: %{_mandir}/man7/*.7.gz}
> +/usr/share/git-core/templates/*
Something like that using %{_datadir} is in the RC branch.
> But the resulting RPM cannot be installed either, at least not in
> standard Fedora Core 2/3/4 installations:
> ...
> Is there at least some documentation which external packages are
> needed, and where to find these?
Patches welcome. Sorry but I need a lot of help when it comes
to binary packaging.
^ permalink raw reply
* Re: Cannot install git RPM
From: Wolfgang Denk @ 2005-08-09 11:07 UTC (permalink / raw)
To: git
In-Reply-To: <20050809104040.B9C61352B36@atlas.denx.de>
I wrote:
> it is not possible to build RPMs from the current git code:
>
> RPM build errors:
> Installed (but unpackaged) file(s) found:
> /usr/share/git-core/templates/description
> /usr/share/git-core/templates/hooks/post-update
> /usr/share/git-core/templates/hooks/update
> /usr/share/git-core/templates/info/exclude
> make: *** [rpm] Error 1
A simple fix is of course:
-> diff -u git-core.spec.in.ORIG git-core.spec.in
--- git-core.spec.in.ORIG 2005-08-09 10:26:50.845877000 +0200
+++ git-core.spec.in 2005-08-09 12:42:06.872310918 +0200
@@ -40,6 +40,7 @@
%{!?_without_docs: %doc Documentation/*.html }
%{!?_without_docs: %{_mandir}/man1/*.1.gz}
%{!?_without_docs: %{_mandir}/man7/*.7.gz}
+/usr/share/git-core/templates/*
%changelog
* Thu Jul 14 2005 Eric Biederman <ebiederm@xmission.com>
But the resulting RPM cannot be installed either, at least not in
standard Fedora Core 2/3/4 installations:
error: Failed dependencies:
perl(Email::Valid) is needed by git-core-0.99.3-1
perl(Mail::Sendmail) is needed by git-core-0.99.3-1
Seems git is depending on more and more stuff which is not available
in standard distros. This makes it not easier for new users...
Is there at least some documentation which external packages are
needed, and where to find these?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There are three principal ways to lose money: wine, women, and en-
gineers. While the first two are more pleasant, the third is by far
the more certain." -- Baron Rothschild, ca. 1800
^ permalink raw reply
* Cannot build git RPM
From: Wolfgang Denk @ 2005-08-09 10:40 UTC (permalink / raw)
To: git
Hello,
it is not possible to build RPMs from the current git code:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/share/git-core/templates/description
/usr/share/git-core/templates/hooks/post-update
/usr/share/git-core/templates/hooks/update
/usr/share/git-core/templates/info/exclude
make: *** [rpm] Error 1
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Computers are not intelligent. They only think they are.
^ permalink raw reply
* Re: Make git-rev-tree obsolete
From: Johannes Schindelin @ 2005-08-09 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhddzygcp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> > therefore it should not be removed. This patch changes git-changes-script
> > over to git-rev-list:
>
> Just to make things clear, "Junio remarked" that Cogito also
> seems to use it as well, so git-rev-tree is not going away.
Oops! My bad.
^ permalink raw reply
* Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Johannes Schindelin @ 2005-08-09 10:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git
In-Reply-To: <7vpssnyge0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> Johannes, could you sanity check the commit change I have in the
> proposed updates branch when things percolate through kernel.org
> mirror network? I ended up pushing it out before I found you
> already did a patch.
I just checked. Three nitpicks:
- I don't like the GNU way to abbreviate long options too much. Either you
know exactly what you're doing, and you use the short form, or you want
to make sure that you have spelt it correctly. Besides, it makes the
code less readable and more prone to errors.
- Multiple -m options was actually a feature of my version of the patch.
- The "case .. in x) .. ;; esac;" construct is sometimes more confusing
than a simple "if", or even a "[ .. = x ] && ..".
As I said, just nitpicks. I didn't test, though. I'll do that when the
commit is in the master branch :-) Maybe I'll even write my first git test
case, who knows?
Ciao,
Dscho
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Catalin Marinas @ 2005-08-09 9:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v1x53zuyv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> If you are happy then I should not complain ;-), and I am
> certainly not complaining, but I still have this feeling that I
> do not get what you are getting at. You can change it to
> directly use pull without intermediate fetch, in order to cope
> with what?
I shouldn't have said anything :-).
StGIT implements a pull command which pops all the patches from the
stack, pulls the latest remote changes and pushes the patches back. I
was lazy and I implemented the pulling stage by simply calling
git-fetch-script and advancing the base of the stack to the value in
FETCH_HEAD. I didn't have any special reason for this and I could have
used git-pull-script instead and not rely on the presence of
FETCH_HEAD. I don't have any preference here.
> Could you explain how you currently do things, and
> what changes I will be making would break the way you currently
> do things please?
If you plan to implement multiple values in FETCH_HEAD, StGIT won't be
able to use this since it doesn't do any merging for the base of the
stack. As I said above, this is not a problem and I was probably wrong
when decided to use git-fetch-script directly and not git-pull-script.
Please let me know if you need more info.
--
Catalin
^ permalink raw reply
* Re: Make git-rev-tree obsolete
From: Jeff Garzik @ 2005-08-09 4:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhddzygcp.fsf@assigned-by-dhcp.cox.net>
On Mon, Aug 08, 2005 at 07:49:26PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> > therefore it should not be removed. This patch changes git-changes-script
> > over to git-rev-list:
>
> Just to make things clear, "Junio remarked" that Cogito also
> seems to use it as well, so git-rev-tree is not going away.
git-changes-script is basically an old Cogito script, as you can see
from looking at the source code.
I only use it for
cd /repos/misc-2.6
git-changes-script -L ../linux-2.6
i.e. where there are two separate trees, rather than separate branches
that I normally work with.
Jeff
^ permalink raw reply
* Re: "Child" information in commit window - and cleanups
From: Linus Torvalds @ 2005-08-09 3:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508081957150.3258@g5.osdl.org>
On Mon, 8 Aug 2005, Linus Torvalds wrote:
>
> It also cleans things up: it marks the text widget as no-wrap, which means
> that it doesn't need to truncate the commit description arbitrarily by
> hand.
Btw, in case anybody wondered: there is no x-axis scroll-bar. I don't
think one is needed, and if you _really_ want to scroll, you can do so
by dragging with the middle-mouse-button.
I have to say, with tcl/tk, "google" + "random typing" can make you appear
to know what the hell you're doing.
Linus
^ permalink raw reply
* "Child" information in commit window - and cleanups
From: Linus Torvalds @ 2005-08-09 3:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
This adds "Child: " lines to the commit window, which tells what children
a commit has.
It also cleans things up: it marks the text widget as no-wrap, which means
that it doesn't need to truncate the commit description arbitrarily by
hand. Also, the description itself is now done by a common helper routine
that handles both the parent and the children.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
[ NOTE! The list of children is "calculated" information, since git itself
doesn't actually keep any child pointers, and that means that it only
lists any children that gitk has seen. There may be other children of a
commit in other branches in the same repository, and gitk will not show
such children that it doesn't know about.
But this is useful for walking up and down the links - you get the same
information as if you had clicked on a link ]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -387,7 +387,7 @@ proc makewindow {} {
set ctext .ctop.cdet.left.ctext
text $ctext -bg white -state disabled -font $textfont \
-width $geometry(ctextw) -height $geometry(ctexth) \
- -yscrollcommand ".ctop.cdet.left.sb set"
+ -yscrollcommand ".ctop.cdet.left.sb set" -wrap none
scrollbar .ctop.cdet.left.sb -command "$ctext yview"
pack .ctop.cdet.left.sb -side right -fill y
pack $ctext -side left -fill both -expand 1
@@ -1704,10 +1704,19 @@ proc selcanvline {w x y} {
selectline $l 1
}
+proc commit_descriptor {p} {
+ global commitinfo
+ set l "..."
+ if {[info exists commitinfo($p)]} {
+ set l [lindex $commitinfo($p) 0]
+ }
+ return "$p ($l)"
+}
+
proc selectline {l isnew} {
global canv canv2 canv3 ctext commitinfo selectedline
global lineid linehtag linentag linedtag
- global canvy0 linespc parents nparents
+ global canvy0 linespc parents nparents children nchildren
global cflist currentid sha1entry
global commentend idtags idline
@@ -1790,15 +1799,15 @@ proc selectline {l isnew} {
set commentstart [$ctext index "end - 1c"]
set comment {}
- foreach p $parents($id) {
- set l "..."
- if {[info exists commitinfo($p)]} {
- set l [lindex $commitinfo($p) 0]
- if {[string length $l] > 32} {
- set l "[string range $l 0 28] ..."
- }
+ if {[info exists parents($id)]} {
+ foreach p $parents($id) {
+ append comment "Parent: [commit_descriptor $p]\n"
+ }
+ }
+ if {[info exists children($id)]} {
+ foreach c $children($id) {
+ append comment "Child: [commit_descriptor $c]\n"
}
- append comment "Parent: $p ($l)\n"
}
append comment "\n"
append comment [lindex $info 5]
^ permalink raw reply
* Re: Make git-rev-tree obsolete
From: Junio C Hamano @ 2005-08-09 2:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508090222190.4076@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> therefore it should not be removed. This patch changes git-changes-script
> over to git-rev-list:
Just to make things clear, "Junio remarked" that Cogito also
seems to use it as well, so git-rev-tree is not going away.
^ permalink raw reply
* Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Junio C Hamano @ 2005-08-09 2:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pavel Roskin, git
In-Reply-To: <Pine.LNX.4.63.0508090140100.3695@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I, for one, like the layout. There are not yet enough files to merit a
> hierarchy, and what's more: I can add the source-directory to my PATH and
> be done by compiling every time I pull.
>
> But you're right in any case, it is post 1.0 discussion material.
For quite some time, I've been wanting to install some of the
stuff under /usr/lib{,exec}/git-core/, but that is a post 1.0
material. I do not care much about the way we organize the
sources at this stage.
Johannes, could you sanity check the commit change I have in the
proposed updates branch when things percolate through kernel.org
mirror network? I ended up pushing it out before I found you
already did a patch.
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Junio C Hamano @ 2005-08-09 2:48 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508081822.24582.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> My point being that I still can say
>>
>> git pull x some_non_default_head
>>
>> with a file "x" in .git/branches.
>
> Is this currently possible?
Not right now, but that is the plan.
> My understanding of .git/branches was that Cogito uses this as mapping of
> remote branches/heads to local branches/refs, and not to store shortcuts for
> remote git repositories.
> IMHO, the above usage is a kind of "type mismatch", as the "x" already
> contains the branch.
You can look at it this way: "x which already contains the
branch" can specify the default branch if command line did not
say anything, but the command line can override it.
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Junio C Hamano @ 2005-08-09 2:48 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linus Torvalds, git
In-Reply-To: <tnxr7d4vi5v.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> OK, I wasn't that clear. Currently git-fetch-script stores the fetched
> head in the FETCH_HEAD file and git-pull-script uses this file to do
> the merging (by passing its content to git-resolve-script).
Correct. I was not planning to change that arrangement.
> Anyway, I
> can easily change StGIT to only use git-pull-script directly, without
> the intermediate fetch.
If you are happy then I should not complain ;-), and I am
certainly not complaining, but I still have this feeling that I
do not get what you are getting at. You can change it to
directly use pull without intermediate fetch, in order to cope
with what? Could you explain how you currently do things, and
what changes I will be making would break the way you currently
do things please? I need to know which detail of the current
implementation behaviour people rely on to avoid breaking
things.
^ permalink raw reply
* Re: [PATCH] Stash away the original head in ORIG_HEAD when resetting.
From: Junio C Hamano @ 2005-08-09 2:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, torvalds
In-Reply-To: <Pine.LNX.4.63.0508081111020.26210@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Since there are not many users of git-commit's *-m* flag right now: Is it
> necessary to confuse CVS people, who expect to be able to write
>
> git commit -m "I did this and that"
>
> I do not want to be too intrusive, but I think up to now there is just the
> mailbox tools which use this feature, and users of git-reset. Thoughts?
I could be talked into renaming the option to something else and
using -m in a way that is CVS compatible.
That flag originally came from JIT, which uses:
-M <commit> literally take the commit message, no editing necessary;
-m <commit> start with commit message in this one but have user edit;
-l <file> use the log message in this file;
-l - read the log message from stdin.
^ 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