* [PATCH] minor Makefile and local-pull.c edits for Darwin
From: Mark Allen @ 2005-05-10 2:11 UTC (permalink / raw)
To: git
Darwin puts all of the openssl functionality into libcrypto not libssl. Also, gcc
complains about the st.size return value in local-pull.c if it's not cast explicitly as a
long.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
Index: Makefile
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/Makefile (mode:100644)
+++ uncommitted/Makefile (mode:100644)
@@ -80,7 +80,11 @@
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
else
SHA1_HEADER=<openssl/sha.h>
- LIBS += -lssl
+ ifdef DARWIN
+ LIBS += -lcrypto
+ else
+ LIBS += -lssl
+ endif
endif
endif
Index: local-pull.c
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/local-pull.c (mode:100644)
+++ uncommitted/local-pull.c (mode:100644)
@@ -71,7 +71,7 @@
close(ofd);
if (status)
fprintf(stderr, "cannot write %s (%ld bytes)\n",
- dest_filename, st.st_size);
+ dest_filename, (long) st.st_size);
else
pull_say("copy %s\n", hex);
return status;
^ permalink raw reply
* Re: [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Morten Welinder @ 2005-05-10 1:36 UTC (permalink / raw)
To: Brandon Philips; +Cc: Petr Baudis, GIT Mailing List
In-Reply-To: <20050509233904.GB878@osuosl.org>
And it is also unhappy when the directory is empty or contains dotfiles only.
Morten
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Junio C Hamano @ 2005-05-10 1:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <20050510002548.GI15712@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> Could I please have s/COMMIT_AUTHOR/COMMITTER/ and
PB> s/OBJECTS/(OBJDIR|OBJECT_DIR)/?
The former sounds much better. The latter how about
GIT_OBJECT_DIRECTORY? Not much longer than the original
SHA1_FILE_DIRECTORY anyway.
PB> (Cogito needs its own git-merge-cache so that the merge goes properly
PB> anyway, and it already (or still) carries its Git around, so I think
PB> it's not applicable to it. Yes, I want and plan to start publishing the
PB> Git changes, I'm already making some steps for that and I hope I have
PB> something to show by tomorrow.)
Sounds good. BTW, what happened to the plan of merging with my
tip you sent a message earlier about?
PB> Yes, I think couple of weeks is too long. :-) I'd say one or two
PB> releases is enough.
I'd leave that to community and Linus to decide when he returns.
PB> Pretty please, add copyright notices at the top of files.
Thanks for pointing it out.
>> +char *gitenv_bc(const char *e)
>> +{
>> + int first, last;
>> + char *val = getenv(e);
>> + if (val)
>> + /* inefficient. caller should use gitenv() not gitenv_bc() */
>> + return val;
PB> Can this ever happen? If doing it at all, I'd expect gitenv_bc() to
PB> rather freak out and die(), the caller is broken.
Point taken.
I've pushed out an updated version that addresses all of the
above issues to git-jc repository [*1*]. Please take a look.
[References]
*1* http://members.cox.net/junkio/
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Daniel Barkalow @ 2005-05-10 0:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <20050510004431.GM15712@pasky.ji.cz>
On Tue, 10 May 2005, Petr Baudis wrote:
> Dear diary, on Tue, May 10, 2005 at 02:38:53AM CEST, I got a letter
> where Daniel Barkalow <barkalow@iabervon.org> told me that...
> > On Mon, 9 May 2005, Junio C Hamano wrote:
> >
> > > >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> > >
> > > DB> While we're at it, it would be useful to have one for what is normally
> > > DB> ".git",...
> > >
> > > If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> > > your only gripe is about git-init-db creating ".git" in the
> > > current working directory regardless of SHA1_FILE_DIRECTORY, I
> > > would agree that what git-init-db does is broken. Not that I
> > > have a suggested "right behaviour" for it, though.
> >
> > It could just create all missing parents of the object directory, which
> > would be better, at least.
>
> What about the index file? Or should git-read-tree take care of that?
Probably whatever writes the index file should take care of making sure it
can be written (if possible).
> > > I once advocated GIT_WORKING_TREE to mean the current project
> > > top, which is the parent directory of ".git". The proposal was
> > > shot down (see archives [*1*]). While I still think that
> > > configuration (or your ".git" location proposal, which is
> > > essentially the equivalent) may sometimes useful, I'd rather not
> > > conflate this environment variable renames with that issue.
> > > They are pretty much independent issues.
> >
> > The reason to tackle them at once is so that there doesn't have to be
> > multiple changeovers.
>
> There should be no changeovers, just additions - the object directory
> and index file location environment variables should stay too.
Definitely true of the index file, since people actually write different
ones. I'm not sure if there's a real use for specifying something
different for the objects directory than BASE + objects, though.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Petr Baudis @ 2005-05-10 0:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505092012340.30848-100000@iabervon.org>
Dear diary, on Tue, May 10, 2005 at 02:38:53AM CEST, I got a letter
where Daniel Barkalow <barkalow@iabervon.org> told me that...
> On Mon, 9 May 2005, Junio C Hamano wrote:
>
> > >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> > DB> While we're at it, it would be useful to have one for what is normally
> > DB> ".git",...
> >
> > If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> > your only gripe is about git-init-db creating ".git" in the
> > current working directory regardless of SHA1_FILE_DIRECTORY, I
> > would agree that what git-init-db does is broken. Not that I
> > have a suggested "right behaviour" for it, though.
>
> It could just create all missing parents of the object directory, which
> would be better, at least.
What about the index file? Or should git-read-tree take care of that?
> But even if this is up to the wrapping scripts, it would be useful to have
> the same environment variable used by those scripts for whatever they want
> to have in there.
Seconded. That is another good reason for having that.
> > I once advocated GIT_WORKING_TREE to mean the current project
> > top, which is the parent directory of ".git". The proposal was
> > shot down (see archives [*1*]). While I still think that
> > configuration (or your ".git" location proposal, which is
> > essentially the equivalent) may sometimes useful, I'd rather not
> > conflate this environment variable renames with that issue.
> > They are pretty much independent issues.
>
> The reason to tackle them at once is so that there doesn't have to be
> multiple changeovers.
There should be no changeovers, just additions - the object directory
and index file location environment variables should stay too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Daniel Barkalow @ 2005-05-10 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7v7ji8vt5c.fsf@assigned-by-dhcp.cox.net>
On Mon, 9 May 2005, Junio C Hamano wrote:
> >>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
>
> DB> While we're at it, it would be useful to have one for what is normally
> DB> ".git",...
>
> If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> your only gripe is about git-init-db creating ".git" in the
> current working directory regardless of SHA1_FILE_DIRECTORY, I
> would agree that what git-init-db does is broken. Not that I
> have a suggested "right behaviour" for it, though.
It could just create all missing parents of the object directory, which
would be better, at least.
> However if you also mean by ".git" the directory refs/heads and
> friends hang underneath, then I have to disagree. That does not
> belong to core GIT, which always expects to run from the top
> level directory that has such directory directly under it, and
> at the same time corresponds to the tree structure the dircache
> describes. There is no need for the environment variable you
> suggest, since it always is the ".git" subdirectory of such a
> directory.
So far, I have never heard of SHA1_FILE_DIRECTORY being used to target
something in .git other than objects. The only use of SHA1_FILE_DIRECTORY
I've heard about is my own in rsh.c, which sets it to [PATH]/objects,
because it has to write object files, most often, to
.../project.git/objects/. You can't really cd to /scm/git<delete> and have
.git/objects refer to the right thing.
My position is still that what refs/*/* gets used for is up to the user,
but the existance and format of the directory is a core thing. In
particular, I want to have atomic methods of modifying these files. (I.e.,
you give commit-cache a */* to write the result to, and it will make sure
that nobody writes to it or reads it expecting to write to it while you're
committing).
But even if this is up to the wrapping scripts, it would be useful to have
the same environment variable used by those scripts for whatever they want
to have in there.
> I once advocated GIT_WORKING_TREE to mean the current project
> top, which is the parent directory of ".git". The proposal was
> shot down (see archives [*1*]). While I still think that
> configuration (or your ".git" location proposal, which is
> essentially the equivalent) may sometimes useful, I'd rather not
> conflate this environment variable renames with that issue.
> They are pretty much independent issues.
The reason to tackle them at once is so that there doesn't have to be
multiple changeovers.
> [References]
> *1* http://marc.theaimsgroup.com/?l=git&m=111412959320946&w=2
I believe that Linus's primary gripe was about changing the expected
location of the working tree, not about changing the expected location of
the git storage. So the .git location proposal is quite different.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: cg-log patches
From: Petr Baudis @ 2005-05-10 0:37 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Sean, GIT Mailing List
In-Reply-To: <20050509121435.GB18382@pasky.ji.cz>
Dear diary, on Mon, May 09, 2005 at 02:14:35PM CEST, I got a letter
where Petr Baudis <pasky@ucw.cz> told me that...
> In git, the parents list is unordered. But this is different in Cogito,
> where the first parent _is_ special. If you are merging _from_ branch B
> _to_ branch A, the order of parents will be always
>
> parent A
> parent B
>
> In practice, it does not make too much difference, but this is one of
> the cases where it makes difference. So I think the current behaviour is
> right.
>
> BTW, this also implies that merges
>
> A --
> \
> B ---+--
>
> and
>
> A ---+--
> /
> B --
>
> are considered as different ones by Cogito
Ok. So you do
A ---+--
/
B --
and now merge A to B, which results in fast-forward and
A ---+----
/ \
B -- --
but when doing cg-log in B, the merge is the wrong way around now.
Sean counterexample works too, it's a good thing to maintain
compatibility with git at this one too.
Still, I would like to have the files list separated. What about one
bullet per parent? Like
* asdf, hjkl, xyzzy
* hjkl, quux
for a regular two-parents merge.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Prototype git commit viewer
From: Paul Mackerras @ 2005-05-10 0:33 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: git
In-Reply-To: <m3fywwjktf.fsf@defiant.localdomain>
Krzysztof Halasa writes:
> Nice. I wonder how well would it work with a longer history, say all
> linux-2.[56] data. It takes gitk ~ 10 seconds to read ~ 1000 Linux
> commits from cache now, on my system.
Any arguments you give to gitk (other than -b and -d) get passed to
git-rev-tree, so you can just look at a section of the tree. (I just
fixed a bug where it would crash if a commit had a parent that wasn't
listed in the git-rev-tree output, so refetch if you want to try it.)
So you can do e.g.
gitk 88d7bd8cb9eb8d64bf7997600b0d64f7834047c5 \
^a2755a80f40e5794ddc20e00f781af9d6320fafb
to see all the commits from v2.6.12-rc4 back to but not including
v2.6.12-rc3 (unfortunately git-rev-tree seems not to cope with being
given tags rather than commit ids).
Ultimately I want to add ways to select the range of commits you want
to look at, e.g. by tags or by dates.
So as long as git-rev-tree remains fast as the history grows, gitk
should remain usable for looking at reasonable-sized chunks of the
history. There are various things I can do to make gitk faster, too,
up to and including tcl bindings for the core git library. :)
> In fact I'm thinking about something working with WWW browser. I've
> written a very simple experimental show-tree tool in C and it seems
> reading current Linux tree (no HTTP output yet) takes 0.065s with it.
>
> Now I'm thinking about output language. (X)HTML seems to be not
> capable (I'm not HTML expert, please correct me if I'm wrong).
>
> Any idea of what can I use?
I think I am even less of an HTML expert than you. :)
Regards,
Paul.
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Petr Baudis @ 2005-05-10 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <20050509201520.GL24216@cip.informatik.uni-erlangen.de>
Dear diary, on Mon, May 09, 2005 at 10:15:20PM CEST, I got a letter
where Thomas Glanzmann <sithglan@stud.uni-erlangen.de> told me that...
> > Here is a patch, requesting for comments.
>
> sounds good. But I would forget about downward compatibility. There is
> no need to maintain it at this early stage.
Sure there is. We are actually far from an early stage now, I'd say.
And what I don't want to see are commits with messed up author
information since people upgraded and did not notice.
> And one thing which bothers me all the time but never spoke up about it:
> There is no way to provide a GIT_COMMIT_DATE. This would be useful for
> vendortracking a CVS repository for example.
You could use GIT_AUTHOR_DATE. :-)
But yes, I actually agree. When you are doing vendortracking of CVS
repository, you have one canonical source of the commit, and when you do
the CVS import twice independently, I think you _want_ the same commit,
since it _is_ the same commit after all (if the history is same too,
obviously).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Petr Baudis @ 2005-05-10 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7vzmv4udyx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, May 10, 2005 at 02:22:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Except that you do not have to specify GIT_OBJECTS and
> GIT_INDEX_FILE separately, that is. Is it what you are aiming
> for?
Yes. Having less things to specify is better. What if another directory
will be added to the git repository? Everything which wants to work with
something else than .git will be broken just because of this.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Petr Baudis @ 2005-05-10 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7vhdhcxj0z.fsf_-_@assigned-by-dhcp.cox.net>
Dear diary, on Mon, May 09, 2005 at 10:05:00PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> - Renames the following environment variables:
>
> New name Old Name
>
> GIT_AUTHOR_DATE AUTHOR_DATE
> GIT_AUTHOR_EMAIL AUTHOR_EMAIL
> GIT_AUTHOR_NAME AUTHOR_NAME
> GIT_COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_EMAIL
> GIT_COMMIT_AUTHOR_NAME COMMIT_AUTHOR_NAME
> GIT_ALTERNATE_OBJECTS SHA1_FILE_DIRECTORIES
> GIT_OBJECTS SHA1_FILE_DIRECTORY
Could I please have s/COMMIT_AUTHOR/COMMITTER/ and
s/OBJECTS/(OBJDIR|OBJECT_DIR)/?
> The transition plan is as follows:
>
> - We will keep the backward compatibility list used by gitenv()
> for now, so the current scripts and user environments
> continue to work as before. The users will get warnings when
> they have old name but not new name in their environment to
> the stderr.
>
> - The Porcelain layers should start using new names. However,
> just in case it ends up calling old Plumbing layer
> implementation, they should also export old names, taking
> values from the corresponding new names, during the
> transition period.
(Cogito needs its own git-merge-cache so that the merge goes properly
anyway, and it already (or still) carries its Git around, so I think
it's not applicable to it. Yes, I want and plan to start publishing the
Git changes, I'm already making some steps for that and I hope I have
something to show by tomorrow.)
> - After a couple of weeks or so, we would drop the
> compatibility support and drop gitenv(). Revert the callers
> to directly call getenv() but keep using the new names.
>
> The last part is probably optional and the transition
> duration needs to be set to a reasonable value.
Yes, I think couple of weeks is too long. :-) I'd say one or two
releases is enough.
> --- /dev/null
> +++ b/gitenv.c
Pretty please, add copyright notices at the top of files.
> +char *gitenv_bc(const char *e)
> +{
> + int first, last;
> + char *val = getenv(e);
> + if (val)
> + /* inefficient. caller should use gitenv() not gitenv_bc() */
> + return val;
Can this ever happen? If doing it at all, I'd expect gitenv_bc() to
rather freak out and die(), the caller is broken.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Junio C Hamano @ 2005-05-10 0:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <20050510001351.GH15712@pasky.ji.cz>
>>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
PB> I think it would be nice to have something like GIT_BASEDIR,
PB> which would default to .git, and the objects directory would
PB> then default to $GIT_BASEDIR/objects and the index file
PB> would default to $GIT_BASEDIR/index.
Yes and no. While I agree that having more things customizable
may be nicer than not having them, I do not see what GIT_BASEDIR
buys us. That is, I cannot come up with a good use scenario
that would be helped by having that environment variable.
Except that you do not have to specify GIT_OBJECTS and
GIT_INDEX_FILE separately, that is. Is it what you are aiming
for?
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Petr Baudis @ 2005-05-10 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7v7ji8vt5c.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, May 10, 2005 at 02:09:19AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
> your only gripe is about git-init-db creating ".git" in the
> current working directory regardless of SHA1_FILE_DIRECTORY, I
> would agree that what git-init-db does is broken. Not that I
> have a suggested "right behaviour" for it, though.
>
> However if you also mean by ".git" the directory refs/heads and
> friends hang underneath, then I have to disagree. That does not
> belong to core GIT, which always expects to run from the top
> level directory that has such directory directly under it, and
> at the same time corresponds to the tree structure the dircache
> describes. There is no need for the environment variable you
> suggest, since it always is the ".git" subdirectory of such a
> directory.
I think it would be nice to have something like GIT_BASEDIR, which would
default to .git, and the objects directory would then default to
$GIT_BASEDIR/objects and the index file would default to
$GIT_BASEDIR/index.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Junio C Hamano @ 2005-05-10 0:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <Pine.LNX.4.21.0505091847050.30848-100000@iabervon.org>
>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:
DB> While we're at it, it would be useful to have one for what is normally
DB> ".git",...
If you mean the parent directory of ${SHA1_FILE_DIRECTORY}, and
your only gripe is about git-init-db creating ".git" in the
current working directory regardless of SHA1_FILE_DIRECTORY, I
would agree that what git-init-db does is broken. Not that I
have a suggested "right behaviour" for it, though.
However if you also mean by ".git" the directory refs/heads and
friends hang underneath, then I have to disagree. That does not
belong to core GIT, which always expects to run from the top
level directory that has such directory directly under it, and
at the same time corresponds to the tree structure the dircache
describes. There is no need for the environment variable you
suggest, since it always is the ".git" subdirectory of such a
directory.
I once advocated GIT_WORKING_TREE to mean the current project
top, which is the parent directory of ".git". The proposal was
shot down (see archives [*1*]). While I still think that
configuration (or your ".git" location proposal, which is
essentially the equivalent) may sometimes useful, I'd rather not
conflate this environment variable renames with that issue.
They are pretty much independent issues.
[References]
*1* http://marc.theaimsgroup.com/?l=git&m=111412959320946&w=2
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Daniel Barkalow @ 2005-05-10 0:07 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: Git Mailing List, darcs-devel
In-Reply-To: <7ihdhc5le2.fsf@lanthane.pps.jussieu.fr>
On Mon, 9 May 2005, Juliusz Chroboczek wrote:
> Hi,
>
> Here are a few notes about Git that should probably be taken into
> account by people working on Git itself or on Git wrappers. The notes
> apply to Linus' Git-0.6, which is the code I'm using in Darcs-git;
> some of them might no longer be applicable to Darcs.
>
>
> 1. Darcs-git uses the fact that Git updates are atomic when reading
> from a Git repository. Darcs-git almost writes to Git repositories
> atomically, with one exception: it performs a non-atomic
> read/update/write cycle on .git/HEAD.
>
> For that reason, I'm taking a high-level lock on .git repositories
> whenever I write them. The lockfile is ``.git/lock''. I haven't
> thought about whether Darcs can be easily coerced into accessing Git
> repos atomically; have people writing Git wrappers found the need for
> a global lock?
I think most things are using the O_CREAT | O_EXCL write to a file and
then rename or link/unlink to the desired location. I have some code to do
this with refs/*/* as well, and I think people have generally settled on
symlinking HEAD to something in refs/heads/. So it shouldn't be necessary
to lock the whole repository, unless you're doing some operation like
swapping two heads.
> 2. The files git.h and git.c in Darcs-git are a simple ``libgit'' that
> contains just enough functionality for Darcs-git; they use the
> functionality of sha1_file.c and read_cache.c from Git-0.6.
>
> I've found a few problems with the interfaces in these files:
>
> - the global variables sha1_file_directory, active_cache, active_nr
> and active_alloc are not marked ``extern'' in cache.h. This breaks
> linkers that don't grok common symbols, such as the one in GHCi
> (silly GHCi).
Should be trivial to fix.
> - the function write_sha1_file takes the metadata and the data in a
> contiguous buffer, which is a problem when the data has been
> allocated by a higher layer. I'm currently working around the
> problem by memcpy-ing everything into a temp buffer, but that's
> obviously not a good thing. I don't care whether write_sha1_file
> is changed to use a writev-like interface, or to take the metadata
> explicitly (as in char *type, unsigned long length).
I've got some patches to make new functions of the write_sha1_file sort
easier to write cleanly (for making git-*-pull clean); it wouldn't be too
hard to have an open/write/close set.
> - there is no (usable) function to write a tree; there's the code in
> write_tree.c, but it's not generally useful. See the function
> ``git_write_tree_done'' in git.c for the type of interface I'm
> thinking of.
I'm working on making this cleaner. Are you wanting to write a tree from
something other than a cache?
I can post my patches, but Linus is on vacation, so they couldn't go into
the mainline until Friday or so anyway.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Prototype git commit viewer
From: Petr Baudis @ 2005-05-10 0:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17023.57405.35272.46557@cargo.ozlabs.ibm.com>
Dear diary, on Tue, May 10, 2005 at 12:12:13AM CEST, I got a letter
where Paul Mackerras <paulus@samba.org> told me that...
> Petr Baudis writes:
>
> > What are its advantages to git-viz?
>
> As a kernel developer, when I do a pull from Linus' tree, the question
> I want to ask is "who has been making what changes?" That's why gitk
> shows the headline and author of each of 30 commits in one screenful.
> AFAICS from the screenshots, git-viz doesn't give me that density of
> information (and neither did bk revtool, for that matter).
>
> It seems to me that git-viz makes the graph topology the primary thing
> and the details of the commits the secondary thing. I want it the
> other way around.
Yes, it looks indeed pretty nice, I have to say after actually looking
at it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* [PATCH Cogito] cg-init breaks if . contains sub-dir
From: Brandon Philips @ 2005-05-09 23:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: GIT Mailing List
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
Hi Petr,
cg-init has the ability to cg-add all files in the current directory.
But if the current directory has a sub directory cg-init breaks because
the `find *` command on line 34 returns directories which cg-add doesn't
accept.
Regards
Brandon Philips
Shameless plug: cogito-0.10 available in Gentoo
--
http://ifup.org
---
cg-init: needs update
Index: cg-init
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/cg-init (mode:100755)
+++ uncommitted/cg-init (mode:100755)
@@ -31,7 +31,7 @@
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * | xargs cg-add
+ find * ! -type d | xargs cg-add
cg-commit -C -m"Initial commit" -e
fi
exit 0
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Junio C Hamano @ 2005-05-09 23:34 UTC (permalink / raw)
To: Brad Roberts
Cc: Petr Baudis, Juliusz Chroboczek, Git Mailing List, darcs-devel
In-Reply-To: <Pine.LNX.4.44.0505091549210.2136-100000@bellevue.puremagic.com>
I'd rather see it done against the tip of the Linus tree.
^ permalink raw reply
* Re: [RFC] Renaming environment variables.
From: Daniel Barkalow @ 2005-05-09 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, H. Peter Anvin, Sean, Linus Torvalds
In-Reply-To: <7vhdhcxj0z.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 9 May 2005, Junio C Hamano wrote:
> H. Peter Anvin mentioned that using SHA1_whatever as an
> environment variable name is not nice and we should instead use
> names starting with "GIT_" prefix to avoid conflicts.
>
> Here is a patch, requesting for comments.
>
> - Renames the following environment variables:
>
> New name Old Name
>
> GIT_AUTHOR_DATE AUTHOR_DATE
> GIT_AUTHOR_EMAIL AUTHOR_EMAIL
> GIT_AUTHOR_NAME AUTHOR_NAME
> GIT_COMMIT_AUTHOR_EMAIL COMMIT_AUTHOR_EMAIL
> GIT_COMMIT_AUTHOR_NAME COMMIT_AUTHOR_NAME
> GIT_ALTERNATE_OBJECTS SHA1_FILE_DIRECTORIES
> GIT_OBJECTS SHA1_FILE_DIRECTORY
While we're at it, it would be useful to have one for what is normally
".git", rather than just ".git/objects". That way the same variable would
be useful for finding other things in the .git directory, and I haven't
heard of any use of SHA1_FILE_DIRECTORY that didn't end in /objects
anyway, and would enable the brokenness in init-db (it creates ".git", and
then tries to create "<obj-dir>/00-ff").
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Juliusz Chroboczek @ 2005-05-09 23:08 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, darcs-devel
In-Reply-To: <427FE938.7050904@zytor.com>
>> In such cases, manual intervention is necessary anyway -- a file could
>> have been written half-way.
> In the case of git, it should not be necessary even then; there might
> be a broken file in the repository but nothing would reference it so
> it shouldn't have any effect. Functionally speaking, operations on
> the git repository are in themselves atomic.
Yes, you're right.
I still prefer using a lockfile to flock -- NFS-safety is important
for us. And experience with the Darcs user base (who are probably
less Unix-savvy then the Git userbase) shows that they have no problem
doing
$ ps
$ rm _darcs/lock
$ darcs check
when Darcs complains about a stray lockfile.
Juliusz
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Petr Baudis @ 2005-05-09 23:02 UTC (permalink / raw)
To: Brad Roberts; +Cc: Juliusz Chroboczek, Git Mailing List, darcs-devel
In-Reply-To: <Pine.LNX.4.44.0505091549210.2136-100000@bellevue.puremagic.com>
Dear diary, on Tue, May 10, 2005 at 12:50:33AM CEST, I got a letter
where Brad Roberts <braddr@puremagic.com> told me that...
> > > - there's no way to have multiple simultaneous caches, short of
> > > hacking at the values of Git's global variables by hand.
> >
> > See the Brad Robert's patches of Apr 21. I've decided not to apply them
> > since it appears a lot has changed since then and it would be some pain;
> > but they may be a worthy starting point for a more up-to-date patch.
> >
> > --
> > Petr "Pasky" Baudis
>
> Since there's interest, I'll pull tip of your tree and re-do them. I
> haven't bothered todate since no one seemed interested. Do you want them
> piece meal like I did last time or just one big diff?
Piece meal would be excellent.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Brad Roberts @ 2005-05-09 22:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Juliusz Chroboczek, Git Mailing List, darcs-devel
In-Reply-To: <20050509212842.GC15712@pasky.ji.cz>
> > - there's no way to have multiple simultaneous caches, short of
> > hacking at the values of Git's global variables by hand.
>
> See the Brad Robert's patches of Apr 21. I've decided not to apply them
> since it appears a lot has changed since then and it would be some pain;
> but they may be a worthy starting point for a more up-to-date patch.
>
> --
> Petr "Pasky" Baudis
Since there's interest, I'll pull tip of your tree and re-do them. I
haven't bothered todate since no one seemed interested. Do you want them
piece meal like I did last time or just one big diff?
Later,
Brad
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: H. Peter Anvin @ 2005-05-09 22:50 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: Git Mailing List, darcs-devel
In-Reply-To: <7ipsw010i5.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek wrote:
>>>I see. Let me know if you decide to use a different name for the
>>>lock file so I can switch to using the same one as yours.
>
>
>>Are you using flock(), or some other contraption that breaks if a
>>process dies unexpectedly?
>
> No, I'm using a file that is created by the NFS-safe equivalent of
> open(O_CREAT | O_EXCL). This is what Darcs has been doing basically
> forever.
>
> Darcs usually doesn't die unexpectedly -- it's a Haskell program, so
> bugs usually manifest themselves with an exception being thrown
> allowing Darcs to clean-up after itself.
>
> The one exception is when Darcs gets killed by the OOM killer (which,
> as you doubtless know, doesn't give any advance warning to a process,
> thus making it impossible for a process to deal with it gracefully).
> In such cases, manual intervention is necessary anyway -- a file could
> have been written half-way.
>
In the case of git, it should not be necessary even then; there might be
a broken file in the repository but nothing would reference it so it
shouldn't have any effect. Functionally speaking, operations on the git
repository are in themselves atomic.
-hpa
^ permalink raw reply
* Re: Darcs-git: a few notes for Git hackers
From: Juliusz Chroboczek @ 2005-05-09 22:46 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: darcs-devel, Git Mailing List
In-Reply-To: <427FE248.7040403@zytor.com>
>> I see. Let me know if you decide to use a different name for the
>> lock file so I can switch to using the same one as yours.
> Are you using flock(), or some other contraption that breaks if a
> process dies unexpectedly?
No, I'm using a file that is created by the NFS-safe equivalent of
open(O_CREAT | O_EXCL). This is what Darcs has been doing basically
forever.
Darcs usually doesn't die unexpectedly -- it's a Haskell program, so
bugs usually manifest themselves with an exception being thrown
allowing Darcs to clean-up after itself.
The one exception is when Darcs gets killed by the OOM killer (which,
as you doubtless know, doesn't give any advance warning to a process,
thus making it impossible for a process to deal with it gracefully).
In such cases, manual intervention is necessary anyway -- a file could
have been written half-way.
Juliusz
^ permalink raw reply
* Re: [RFC] allow file list editing during cg-commit
From: Eugene Surovegin @ 2005-05-09 22:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050509084606.GD3599@pasky.ji.cz>
On Mon, May 09, 2005 at 10:46:06AM +0200, Petr Baudis wrote:
[snip]
> The only thing to watch out for is that cg-commit -C produces no such
> list at all; it should deal with that and tell the user he is not going
> to be able to control what is going to be committed then.
>
> Another thing is that at the moment you modify the file list, you should
> set customfiles - otherwise you will commit even cg-adds and cg-rms of
> files you didn't select. But do that really only when you change the
> file list, since it is more expensive.
>
> You should also place an appropriate hint near the CG: lines, saying
> that removing some of them will limit the list of files to be committed.
OK, how about the following patch? I tried to address all issues you
mentioned and also $merging case as well.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Index: cg-commit
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/cg-commit (mode:100755)
+++ uncommitted/cg-commit (mode:100755)
@@ -111,12 +111,16 @@
rm $LOGMSG $LOGMSG2
die 'Nothing to commit'
fi
+ if [ ! "$merging" ]; then
+ echo "CG: By deleting lines beginning with CG:F the associated file" >>$LOGMSG
+ echo "CG: will be removed from the commit list." >>$LOGMSG
+ fi
echo "CG:" >>$LOGMSG
echo "CG: Modified files:" >>$LOGMSG
for file in "${commitfiles[@]}"; do
# TODO: Prepend a letter describing whether it's addition,
# removal or update. Or call git status on those files.
- echo "CG: $file" >>$LOGMSG
+ echo "CG:F $file" >>$LOGMSG
[ "$msgs" ] && ! [ "$forceeditor" ] && echo $file
done
fi
@@ -131,6 +135,17 @@
rm $LOGMSG $LOGMSG2
die 'Commit message not modified, commit aborted'
fi
+ if [ ! "$ignorecache" ] && [ ! "$merging" ]; then
+ eval newcommitfiles=($(grep ^CG:F $LOGMSG2 | sed 's/^CG:F//'))
+ if [ ! "${newcommitfiles[*]}" ]; then
+ rm $LOGMSG $LOGMSG2
+ die 'Nothing to commit'
+ fi
+ if [ "${commitfiles[*]}" != "${newcommitfiles[*]}" ]; then
+ commitfiles="${newcommitfiles[*]}"
+ customfiles="${commitfiles[*]}"
+ fi
+ fi
else
cat >>$LOGMSG2
fi
^ 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