* Re: Add an empty directory?
From: Junio C Hamano @ 2005-08-13 19:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813180008.GJ5608@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> the object databases supports it, but the index file does not. But yes,
> it should be supported, I think.
I think if this is done correctly "read-tree -m -u" two-tree
switch could even remove directories that existed in the old
tree but not in the new tree that has become empty.
On the other hand, although I haven't started looking, adding
this to index file might involve a major surgery. Practically
everybody expects it is does not have an directory entry. This
includes reading trees, merging two or more stages, finding
directory/file conflicts, etc. etc...
^ permalink raw reply
* Re: Add an empty directory?
From: Linus Torvalds @ 2005-08-13 19:41 UTC (permalink / raw)
To: Carl Baldwin; +Cc: Petr Baudis, git
In-Reply-To: <20050813181945.GA2191@hpsvcnb.fc.hp.com>
On Sat, 13 Aug 2005, Carl Baldwin wrote:
>
> The bottom line is that I don't really see many situations where it is
> absolutely necessary but it is a convenience. Not supporting it may
> seem like an artificial limit that really didn't need to be there.
Well, there is an argument for not supporting it, namely that the way
patches work, traditionally a directory that became empty is deleted
(because patches have no way of saying "remove directory" or "create
directory").
So a system where the existence of a directory flows from the existence of
the files within the directory will automatically always do the right
thing with patches floating around.
Which is a big deal for me, since most of the kernel development still
ends up being done with patches. Yes, we merge things with git, but a lot
of the development is about passing patches around for review and
commentary.
And the thing is, you can always create the directory in your workspace.
Git won't care, and won't know about it, but there's really no downside to
it.
Linus
^ permalink raw reply
* Re: Add an empty directory?
From: Petr Baudis @ 2005-08-13 19:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.58.0508131238150.3553@g5.osdl.org>
Dear diary, on Sat, Aug 13, 2005 at 09:41:45PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Sat, 13 Aug 2005, Carl Baldwin wrote:
> >
> > The bottom line is that I don't really see many situations where it is
> > absolutely necessary but it is a convenience. Not supporting it may
> > seem like an artificial limit that really didn't need to be there.
>
> Well, there is an argument for not supporting it, namely that the way
> patches work, traditionally a directory that became empty is deleted
> (because patches have no way of saying "remove directory" or "create
> directory").
If we have rename patches, why couldn't our patches deal with
directories as well? And git-apply, cg-patch etc might have a way to
behave in a "traditional" way for non-git patches and if a patch removes
all files in a directory, kill the directory.
That is, I would solve this on the SCM<->patches boundary, not
fundamentally limit the SCM itself.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: My Itchlist
From: Petr Baudis @ 2005-08-13 20:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508051924390.3258@g5.osdl.org>
Dear diary, on Sat, Aug 06, 2005 at 04:39:01AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Fri, 5 Aug 2005, Junio C Hamano wrote:
> > - teach git-apply "reverse" and possibly "fuzz".
> >
> > I think this might help Porcelain; currently they have to
> > interpret git extended diff headers themselves.
>
> Reverse would definitely be useful. "fuzz" is really pretty dangerous. I
> think that once a a patch doesn't apply, you really want to have helper
> tools like a graphical "wiggle" etc, and that really means that it's not
> "git-apply", it's something totally different.
I don't know, but I come across fuzzy patches quite frequently and any
problems have been always _extremely_ rare. And in any case, I can (and
do) verify it right away by doing cg-diff and checking what changes did
the patch really do.
> And quite frankly, if you have a tool that can handle unified diffs
> already, then extending it for the git rename stuff should be pretty easy.
> It's not like we haven't wanted renaming patches for at least a _decade_
> already, it's just that nobody ever did them.
That reminds me I should finally add support for renames to cg-patch...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Add an empty directory?
From: Carl Baldwin @ 2005-08-13 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Baldwin, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0508131238150.3553@g5.osdl.org>
On Sat, Aug 13, 2005 at 12:41:45PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 13 Aug 2005, Carl Baldwin wrote:
> >
> > The bottom line is that I don't really see many situations where it is
> > absolutely necessary but it is a convenience. Not supporting it may
> > seem like an artificial limit that really didn't need to be there.
>
> Well, there is an argument for not supporting it, namely that the way
> patches work, traditionally a directory that became empty is deleted
> (because patches have no way of saying "remove directory" or "create
> directory").
>
> So a system where the existence of a directory flows from the existence of
> the files within the directory will automatically always do the right
> thing with patches floating around.
I see your point here. However, if git supported it then any particular
usage model on top of git could choose to do it either way. If it
doesn't then that flexibility is not there.
> Which is a big deal for me, since most of the kernel development still
> ends up being done with patches. Yes, we merge things with git, but a lot
> of the development is about passing patches around for review and
> commentary.
>
> And the thing is, you can always create the directory in your workspace.
> Git won't care, and won't know about it, but there's really no downside to
> it.
>
> Linus
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [PATCH] Added hook in git-receive-pack
From: Josef Weidendorfer @ 2005-08-13 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe81myc4.fsf@assigned-by-dhcp.cox.net>
On Saturday 13 August 2005 21:27, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> > Or is there already an easy way to detect the fast-forward situation in
> > the script?
>
> Since you are given old and new, presumably you can do
> merge-base in the hook to see what it yields?
Ah, yes, thanks.
A proposed update for the example hook (one change actually is a fix):
Fixed/Extended example for update hook
---
diff --git a/templates/hooks--update b/templates/hooks--update
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -1,6 +1,7 @@
#!/bin/sh
#
# An example hook script to mail out commit update information.
+# Called by git-receive-pack with arguments: refname sha1-old sha1-new
#
# To enable this hook:
# (1) change the recipient e-mail address
@@ -12,10 +13,15 @@ recipient="commit-list@mydomain.xz"
if expr "$2" : '0*$' >/dev/null
then
echo "Created a new ref, with the following commits:"
- git-rev-list --pretty "$2"
+ git-rev-list --pretty "$3"
else
- echo "New commits:"
- git-rev-list --pretty "$3" "^$2"
+ $base=$(git-merge-base "$2" "$3")
+ if [ $base == "$2" ]; then
+ echo "New commits:"
+ else
+ echo "Rebased ref, commits from common ancestor:"
+ fi
+ git-rev-list --pretty "$3" "^$base"
fi |
mail -s "Changes to ref $1" "$recipient"
exit 0
^ permalink raw reply
* Re: [patch] possible memory leak in diff.c::diff_free_filepair()
From: Yasushi SHOJI @ 2005-08-13 21:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viry9my6k.fsf@assigned-by-dhcp.cox.net>
At Sat, 13 Aug 2005 12:30:59 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <yashi@atmark-techno.com> writes:
>
> > When I run git-diff-tree on big change, it seems the command eats so
> > much memory. so I just put git under valgrind to see what's going on.
> >
> > diff_free_filespec_data() doesn't free diff_filespec itself. is this
> > because in merge_broken() filespec itself is used but fliespec data
> > need to be freed?
>
> Thanks for the patch. I am wondering if the same leak exists in
> diff_free_filepair(), which frees the filespec data without
> freeing filespec itself for both sides. If this is something
> you can trap easily with valgrind I would really appreciate it.
oops. probably my english wasn't clear. my patch fixes
diff_free_filepair().
the reason I asked about merge_broken() was that those two functions
are the only functions calling diff_free_filespec_data(). it's first
time reading git source code and still learning ;)
--
yashi
^ permalink raw reply
* Re: [patch] possible memory leak in diff.c::diff_free_filepair()
From: Junio C Hamano @ 2005-08-13 21:31 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <877jepo87m.wl@mail2.atmark-techno.com>
Yasushi SHOJI <yashi@atmark-techno.com> writes:
> oops. probably my english wasn't clear. my patch fixes
> diff_free_filepair().
No, my reading of your patch when I wrote that message was
wrong. The attached is what I ended up doing based on your
patch. It does not seem to barf with the following test on
either git repository itself nor recent linux-2.6 repository,
which is a good sign.
$ export MALLOC_CHECK_=2
$ ./git-rev-list HEAD |
./git-diff-tree --stdin -r -B -C --find-copies-harder |
sed -ne '/^[^:]/p;/ [MRCDA][0-9][0-9]* /p'
When the command is run on linux-2.6 repository, virtual memory
consumption of git-diff-tree command skyrockets to about half a
gig, because it maps all files in two adjacent revisions of the
entire kernel tree. But it seems to reclaim things reasonably
well and goes back down to less than 10m when it starts to
process the next commit pair.
------------
From: Yasushi SHOJI <yashi@atmark-techno.com>
Date: 1123930736 +0900
[PATCH] plug memory leak in diff.c::diff_free_filepair()
When I run git-diff-tree on big change, it seems the command eats so
much memory. so I just put git under valgrind to see what's going on.
diff_free_filespec_data() doesn't free diff_filespec itself.
[jc: I ended up doing things slightly differently from Yasushi's
patch. The original idea was to use free_filespec_data() only to
free the data portion and keep useing the filespec itself, but
no existing code seems to do things that way, so I just yanked
that part out.]
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 9 ++++-----
diffcore-break.c | 4 ++--
diffcore.h | 2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
20226fa40d48069b55cf165c9e197a003e1608a8
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -405,14 +405,13 @@ int diff_populate_filespec(struct diff_f
return 0;
}
-void diff_free_filespec_data(struct diff_filespec *s)
+void diff_free_filespec(struct diff_filespec *s)
{
if (s->should_free)
free(s->data);
else if (s->should_munmap)
munmap(s->data, s->size);
- s->should_free = s->should_munmap = 0;
- s->data = NULL;
+ free(s);
}
static void prep_temp_blob(struct diff_tempfile *temp,
@@ -769,8 +768,8 @@ struct diff_filepair *diff_queue(struct
void diff_free_filepair(struct diff_filepair *p)
{
- diff_free_filespec_data(p->one);
- diff_free_filespec_data(p->two);
+ diff_free_filespec(p->one);
+ diff_free_filespec(p->two);
free(p);
}
diff --git a/diffcore-break.c b/diffcore-break.c
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -231,8 +231,8 @@ static void merge_broken(struct diff_fil
dp = diff_queue(outq, d->one, c->two);
dp->score = p->score;
- diff_free_filespec_data(d->two);
- diff_free_filespec_data(c->one);
+ diff_free_filespec(d->two);
+ diff_free_filespec(c->one);
free(d);
free(c);
}
diff --git a/diffcore.h b/diffcore.h
--- a/diffcore.h
+++ b/diffcore.h
@@ -43,7 +43,7 @@ extern void fill_filespec(struct diff_fi
unsigned short);
extern int diff_populate_filespec(struct diff_filespec *, int);
-extern void diff_free_filespec_data(struct diff_filespec *);
+extern void diff_free_filespec(struct diff_filespec *);
struct diff_filepair {
struct diff_filespec *one;
^ permalink raw reply
* [RFC][PATCH] Rewriting revs in place in push target repository
From: Petr Baudis @ 2005-08-13 21:47 UTC (permalink / raw)
To: git
Rewrite refs in place in receive-pack & friends
When updating a ref, it would write a new file with the new ref and
then rename it, overwriting the original file. The problem is that
this destroys permissions and ownership of the original file, which is
troublesome especially in multiuser environment, like the one I live in.
This might be controversial, but it's a showbreaker for me wrt. pushing
now. Some alternative solution barely solving my particular situation
might be surely worked out, but this is more general. The question is:
* Does this break atomicity?
I think it does not in real setups, since thanks to O_RDWR the
file should be overwritten only when the write() happens.
Can a 41-byte write() be non-atomic in any real conditions?
* Does this break with full disk/quota?
I'm not sure - we are substituting 41 bytes by another 41
bytes; will the system ever be evil enough to truncate the
file, then decide the user is over his quota and not write
the new contents?
Signed-off-by: Petr Baudis <pasky@suse.cz>
diff --git a/receive-pack.c b/receive-pack.c
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -92,13 +92,7 @@ static int run_update_hook(const char *r
static int update(const char *name,
unsigned char *old_sha1, unsigned char *new_sha1)
{
- char new_hex[60], *old_hex, *lock_name;
- int newfd, namelen, written;
-
- namelen = strlen(name);
- lock_name = xmalloc(namelen + 10);
- memcpy(lock_name, name, namelen);
- memcpy(lock_name + namelen, ".lock", 6);
+ char new_hex[60], *old_hex;
strcpy(new_hex, sha1_to_hex(new_sha1));
old_hex = sha1_to_hex(old_sha1);
@@ -106,38 +100,38 @@ static int update(const char *name,
return error("unpack should have generated %s, "
"but I can't find it!", new_hex);
- safe_create_leading_directories(lock_name);
-
- newfd = open(lock_name, O_CREAT | O_EXCL | O_WRONLY, 0666);
- if (newfd < 0)
- return error("unable to create %s (%s)",
- lock_name, strerror(errno));
-
- /* Write the ref with an ending '\n' */
- new_hex[40] = '\n';
- new_hex[41] = 0;
- written = write(newfd, new_hex, 41);
- /* Remove the '\n' again */
- new_hex[40] = 0;
-
- close(newfd);
- if (written != 41) {
- unlink(lock_name);
- return error("unable to write %s", lock_name);
- }
if (verify_old_ref(name, old_hex) < 0) {
- unlink(lock_name);
return error("%s changed during push", name);
}
if (run_update_hook(name, old_hex, new_hex)) {
- unlink(lock_name);
return error("hook declined to update %s\n", name);
}
- else if (rename(lock_name, name) < 0) {
- unlink(lock_name);
- return error("unable to replace %s", name);
- }
else {
+ char *name2;
+ int newfd, written;
+
+ name2 = strdup(name);
+ safe_create_leading_directories(name2);
+ free(name2);
+
+ newfd = open(name, O_CREAT | O_RDWR, 0666);
+ if (newfd < 0)
+ return error("unable to create %s (%s)",
+ name, strerror(errno));
+
+ /* Write the ref with an ending '\n' */
+ new_hex[40] = '\n';
+ new_hex[41] = 0;
+ written = write(newfd, new_hex, 41);
+ /* Remove the '\n' again */
+ new_hex[40] = 0;
+
+ close(newfd);
+ if (written != 41) {
+ unlink(name);
+ return error("unable to write %s", name);
+ }
+
fprintf(stderr, "%s: %s -> %s\n", name, old_hex, new_hex);
return 0;
}
^ permalink raw reply
* Re: [RFC][PATCH] Rewriting revs in place in push target repository
From: Linus Torvalds @ 2005-08-13 22:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050813214725.GM5608@pasky.ji.cz>
On Sat, 13 Aug 2005, Petr Baudis wrote:
>
> * Does this break atomicity?
>
> I think it does not in real setups, since thanks to O_RDWR the
> file should be overwritten only when the write() happens.
> Can a 41-byte write() be non-atomic in any real conditions?
That's not the problem.
The problem is that your change means that there is no locking, and you
now can have two writers that both update the same file, and they _both_
think that they succeed. They'll both read the old contents, decide that
it still is the one from before the push, and then they'll both do the
write.
And yes, in most (all?) sane filesystems, the end result is that one of
them "wins", and the end result is a nice 41-byte file. But the problem is
that the other write just totally got lost, and the person doing the push
_thought_ he had updated the thing, but never did.
To make things worse, with NFS and client-side caching, different clients
that look at the tree at around that time can literally see _different_
heads winning the race. One of the writers wrote "first", and that client
(and other NFS clients doing a read at that time) will see it succeed. But
then the other pusher writes, and now people will see _that_ one succeed.
Confusion reigns.
In contrast, with the "create lock-file and rename" thing, if there is a
race, somebody will win, and the loser will hopefully know they lost.
> * Does this break with full disk/quota?
>
> I'm not sure - we are substituting 41 bytes by another 41
> bytes; will the system ever be evil enough to truncate the
> file, then decide the user is over his quota and not write
> the new contents?
Probably not.
But how about you just try to copy the permission/group of the original
file before you do the rename? I assume that if you're depending on
permissions, it's either a shared group or by having the thing writable by
others, so doing a
if (!fstat(oldfd, &st)) {
fchown(fd, (uid_t) -1, st.st_gid);
fchmod(fd, st.st_mode & ALLPERMS);
}
.. do rename here ..
which should get you where you want, no?
Linus
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Ryan Anderson @ 2005-08-13 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <7v64uaqknh.fsf@assigned-by-dhcp.cox.net>
On Sat, Aug 13, 2005 at 01:57:22AM -0700, Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
> > See, for example, the history on git-rename-script for why this is good.
>
> Why do you think it is a good example? What happens when next
> time somebody rewrites it in C?
Well, I was really responding to the comment about "-script" being
better than ".sh", as trying ".sh", ".pl", ".php", etc, would rapidly
be annoying.
Honestly, I think the biggest argument against the "-script" suffix is
related to man-page usage: It requires significant knowledge of the Git
project to figure out what name variant to use to find the man page.
(There are other problems with man pages, but I'll address those
seperately now that they have occurred to me.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Petr Baudis @ 2005-08-13 22:28 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <20050813222512.GA6844@mythryan2.michonline.com>
Dear diary, on Sun, Aug 14, 2005 at 12:25:12AM CEST, I got a letter
where Ryan Anderson <ryan@michonline.com> told me that...
> Honestly, I think the biggest argument against the "-script" suffix is
> related to man-page usage: It requires significant knowledge of the Git
> project to figure out what name variant to use to find the man page.
.oO(Hey, tcl has own man section as well!)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: git/cogito workshop/bof at linuxconf au?
From: Martin Langhoff @ 2005-08-13 23:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT
In-Reply-To: <Pine.LNX.4.58.0508131111270.19049@g5.osdl.org>
On 8/14/05, Linus Torvalds <torvalds@osdl.org> wrote:
> I was planning to be there. I like lca, but passed it over this year
> because of it being in Canberra
And how are things lining up for the upcoming one (January 2006, Dunedin, NZ)?
> > I would gladly try and organize a workshop, but I am far from fluent
> > with git, so I won't go at it alone. Any takers? Call for papers ends
> > 5th September, not too far ahead. We have to register our interest
> > _now_.
>
> I'm no good with papers, though.
Workshops and BOFs don't need to be paper-backed at all. Though it's
not unlikely that someone with an interest in SCM theory would write a
paper covering git. I think the main interest would be to bring git
practical usage to the masses.
There's a lot of interest, but the barriers of entry are somewhat
high, with the codebase moving fast, and some of the concepts
requiring re-learning of what to expect from an SCM. Perhaps no so
much among kernel hackers, but the general populace is largely still
laden with cvs/svn and their mindset.
cheers,
martin
^ permalink raw reply
* Re: Cloning speed comparison
From: H. Peter Anvin @ 2005-08-13 23:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0508122223280.19049@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 12 Aug 2005, H. Peter Anvin wrote:
>
>>Running it over ssh would be a good way to do authentication...
>
>
> Well, if you have ssh as an option, you don't need git-daemon any more,
> since the protocol that git-daemon does runs quite well over ssh on its
> own...
>
> The only point of git-daemon really is when you don't have ssh access (ie
> you may want to give people a limited interface, but not full ssh). Ie
> as-is, it's only for anonymous reads of a git archive, but it obviously
> _could_ do more.
>
Okay. So use git-daemon for the anonymous users, and run the git
protocol over ssh for writing. Seems easy enough for me.
-hpa
^ permalink raw reply
* Re: git/cogito workshop/bof at linuxconf au?
From: Linus Torvalds @ 2005-08-13 23:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f905081316056e83ebec@mail.gmail.com>
On Sun, 14 Aug 2005, Martin Langhoff wrote:
>
> And how are things lining up for the upcoming one (January 2006, Dunedin, NZ)?
Dunno yet. I have a policy of trying to travel with the whole family,
which means I'll have to decide whether I'm willing to put that much money
into it, or whether some poor unsuspecting company can help sponsor me ;)
We'll see.
> There's a lot of interest, but the barriers of entry are somewhat
> high, with the codebase moving fast, and some of the concepts
> requiring re-learning of what to expect from an SCM. Perhaps no so
> much among kernel hackers, but the general populace is largely still
> laden with cvs/svn and their mindset.
Yeah. We do not have a nice paper explaining the concepts and usage. The
tutorial isn't really in-depth enough (it doesn't even mention a lot of
the helper scripts or even some of the core stuff). The old README started
out explaining some of the concepts, but it's _way_ of out date in all
usage respects.
Pasky has the Overview thing, which gets pointed to by kernel.org, and
which could be expanded upon a lot.
I'll happily help anybody who wants to try to write some nice
documentation (answer questions etc), but I'm just not very good at doing
it myself.
Linus
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Ryan Anderson @ 2005-08-13 23:57 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: David Lang, git
In-Reply-To: <20050812103555.GG5411@kiste.smurf.noris.de>
On Fri, Aug 12, 2005 at 12:35:55PM +0200, Matthias Urlichs wrote:
> David Lang:
> > after so many years of software development (and with the policy of never
> > having conflicting command names) what three letter combinations are still
> > avilable?
> >
> Lots.
>
> > I'm assuming that the much smaller pool of two letter commands was long
> > since exhausted, but if not what two letter commands are available?
> >
> Lots of them, I hope, but all of them obscure.
>
> We even have 25 one-letter commands that are free. My /usr/bin/ only has
> 'w'. And if we run out, we could branch off into other alphabets;
> unfortunately, not everybody has a quick way to type an ??. Or ??. Or ???. ;-)
"gt" seems free on my machine here. I haven't poke around at all the
other ones that have slightly different sets of software, but searching
on the Debian packages search engine:
http://packages.debian.org/cgi-bin/search_contents.pl?word=%2Fusr%2Fbin%2Fgt&searchmode=searchfiles&case=insensitive&version=unstable&arch=i386
cogito in Debian seems to have taken it already for git, anyway.
We can make the conversion easy for people by providing this shell
script for a few weeks:
#!/bin/sh
echo "Don't get a git - use gt!
gt $*
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Matthias Urlichs @ 2005-08-14 0:11 UTC (permalink / raw)
To: Ryan Anderson; +Cc: David Lang, git
In-Reply-To: <20050813235716.GB6844@mythryan2.michonline.com>
Hi,
Ryan Anderson:
>
> #!/bin/sh
> echo "Don't get a git - use gt!
Ouch.
> echo "Don't get a git - use gt!" >&2
if at all.
--
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
- -
USENET would be a better laboratory if there were more labor and less oratory.
-- Elizabeth Haley
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Junio C Hamano @ 2005-08-14 0:48 UTC (permalink / raw)
To: git
In-Reply-To: <20050813235716.GB6844@mythryan2.michonline.com>
Debian folks on the list: We had to make this ugly hack in
our Debianization because Debian heavyweights did not like
to see "Conflicts:" and us lowly new maintainers needed to
obey their wishes.
Linus: The alleged name clash appears to be a Debian
specific problem. No other distribution seem to ship GNU
interactive tools and hence have this name clash. Debian
folks have not even substantiated their claim that the other
GIT is so popular that name clash with it is a bad thing.
JC: Well, here is the popcon numbers. I'll let people
decide if these numbers illustrate that the other GIT is so
popular that we cannot take over its name.
In a sense, both Linus and myself have been unfair to Debian
folks on the list. Worrying about the name clash with the other
GIT so much to change our name was not something they liked to
do to begin with.
> Personally, I'm a mugwump, and I don't care who yields as long as it
> takes place and things can then proceed at their usual pace.
Yes, and that is what Linus and myself are saying. We would
rather stay outside the name politics, which is internal to a
particular distribution. Linus and I were trying to give
ammunition for the Debian folks on the list to make an argument.
Linus said that our GIT installs /usr/bin/git everywhere else
without the name clash problem. I said that the other GIT does
not seem to be used that much even on Debian. From these facts,
they could make an argument that, if Debian as a distribution
wants to stay compatible with other distributions, either (1) it
should tolerate Conflict: and let us install /usr/bin/git, or
(2) get the other GIT renamed. It is up to the folks pushing
Debianization of our GIT to the Debian official archive which
recommendation to make and deal with the Debian heavyweights.
Another thing to note is that it is not unusual for an official
Debian package to have a patch to debian/* files even when the
upstream sources have some such Debianization files. The Debian
folks on the list could take that approach without first
proposing to change the name of /usr/bin/git worldwide. I, as a
Debian user [*1*], would be perfectly happy if the Debianization
of our GIT did not ship "/usr/bin/git", and told the user to
copy "/usr/share/doc/git-core/examples/git" to $HOME/bin/ and
put $HOME/bin at the beginning of the PATH [*2*]. Maybe such a
Debianization would ship with a modified tutorial that has a
paragraph to remind the user about that as well.
[Footnote]
*1* I do not have a single RPM machine at home nor
workplace. Practically everything I touch run Debian.
*2* Even install script offering a choice to make a symlink
/usr/local/bin/git pointing at /usr/bin/git-core-scm would be
possible, but that would only be acceptable on a single-user
machine.
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Junio C Hamano @ 2005-08-14 0:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vek8xl4xi.fsf@assigned-by-dhcp.cox.net>
Oops, sorry that was not something ready to be sent out. Please
discard.
^ permalink raw reply
* Re: [RFC][PATCH] Rewriting revs in place in push target repository
From: Junio C Hamano @ 2005-08-14 0:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813214725.GM5608@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Rewrite refs in place in receive-pack & friends
>
> When updating a ref, it would write a new file with the new ref and
> then rename it, overwriting the original file. The problem is that
> this destroys permissions and ownership of the original file, which is
> troublesome especially in multiuser environment, like the one I live in.
Hmph. If a repo is _really_ used multiuser then you should not
have to care about ownership. If you can write into a
repository for a project (implying that you are a member of that
project group), and if your umask is set up correctly (meaning
it is 002 or looser), and with g+s bit on the directory at the
repository root level when it was created, shouldn't your newly
created ref file be also writable by others in that project?
^ permalink raw reply
* Re: [RFC][PATCH] Rewriting revs in place in push target repository
From: Linus Torvalds @ 2005-08-14 2:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vwtmpjq17.fsf@assigned-by-dhcp.cox.net>
On Sat, 13 Aug 2005, Junio C Hamano wrote:
>
> Petr Baudis <pasky@suse.cz> writes:
> > Rewrite refs in place in receive-pack & friends
> >
> > When updating a ref, it would write a new file with the new ref and
> > then rename it, overwriting the original file. The problem is that
> > this destroys permissions and ownership of the original file, which is
> > troublesome especially in multiuser environment, like the one I live in.
>
> Hmph. If a repo is _really_ used multiuser then you should not
> have to care about ownership.
I think Pasky's usage is that different heads are owned by different
groups and/or users, and he wants to use the filesystem permissions to
determine who gets to update which branch. Which is reasonable in a way.
On the other hand, I don't think filesystem permissions are really very
useful. I think it's more appropriate to use triggers to say something
like "only allow people in the 'xyz' group to write to this head".
Obviously, triggers aren't about _security_ - somebody who has write
permissions to the tree can always screw up others. But triggers are fine
for things like branch ownership, where you trust your users, but you just
want to avoid mistakes.
So a trigger might be something like
#!/bin/sh
. git-sh-setup-script
branch="$1"
old="$2"
new="$3"
if [ -e $GIT_DIR/permissions/$branch ]; then
id=$(id -un)
grep -q "^$id$" $GIT_DIR/permissions/$branch ||
die "You're not allowed to write to $branch"
fi
true
and that would allow you to list all users that are allowed to write to
the branch in $GIT_DIR/permissions/<branchname>.
Totally untested, of course. But the concept should work.
Linus
^ permalink raw reply
* Re: [RFC][PATCH] Rewriting revs in place in push target repository
From: Chris Wedgwood @ 2005-08-14 2:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050813214725.GM5608@pasky.ji.cz>
On Sat, Aug 13, 2005 at 11:47:25PM +0200, Petr Baudis wrote:
> I think it does not in real setups, since thanks to O_RDWR the
> file should be overwritten only when the write() happens.
> Can a 41-byte write() be non-atomic in any real conditions?
yes
if you journal metadata only you can see a file extended w/o having
the block flushed
^ permalink raw reply
* sending changesets from the middle of a git tree
From: Steve French @ 2005-08-14 3:35 UTC (permalink / raw)
To: git
Just to confirm a recent answer to questions on lkml ...
1) There is no way to send a particular changeset from the "middle" of a
set from one tree to another, without exporting it as a patch or
rebuilding a new git tree. I have two changesets that, after testing
last week, I now consider more important to send upstream than the few
earlier and later changesets. If I export those two changesets as
patches, and send them on. presumably I lose the changset comments etc.
and then when the upstream tree is merged back, it might look a little
odd in the changeset history.
2) There is no way to update the comment field of a changeset after it
goes in (e.g. to add a bugzilla bug number for a bug that was opened
just after the fix went in).
3) There is no way to do a test commit of an individual changeset
against a specified tree (to make sure it would still merge cleanly,
automatically).
Are there easier ways to do any of these?
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Ryan Anderson @ 2005-08-14 4:02 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <42FEBC16.9050309@austin.rr.com>
On Sat, Aug 13, 2005 at 10:35:50PM -0500, Steve French wrote:
> Just to confirm a recent answer to questions on lkml ...
>
> 1) There is no way to send a particular changeset from the "middle" of a
> set from one tree to another, without exporting it as a patch or
> rebuilding a new git tree. I have two changesets that, after testing
> last week, I now consider more important to send upstream than the few
> earlier and later changesets. If I export those two changesets as
> patches, and send them on. presumably I lose the changset comments etc.
> and then when the upstream tree is merged back, it might look a little
> odd in the changeset history.
You can keep most of the metadata you want with "git format-patch".
Extract the changes you need, mail them off.
When you later merge things back together, it should be a trivial merge,
hopefully.
> 2) There is no way to update the comment field of a changeset after it
> goes in (e.g. to add a bugzilla bug number for a bug that was opened
> just after the fix went in).
No, a commit is immutable. You can use "git format-patch" to rebase things if
you need. I prefer to use "git format-patch --mbox", edit what I need
to, then use git-applymbox to rebase it all against a clean tree.
> 3) There is no way to do a test commit of an individual changeset
> against a specified tree (to make sure it would still merge cleanly,
> automatically).
Not sure on this one - in this case, it almost sounds like you want the
feature set of StGit, and/or quilt. (If "quilt push" succeeds, clearly
it still merges cleanly.)
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Linus Torvalds @ 2005-08-14 5:03 UTC (permalink / raw)
To: Steve French; +Cc: git
In-Reply-To: <42FEBC16.9050309@austin.rr.com>
On Sat, 13 Aug 2005, Steve French wrote:
>
> 1) There is no way to send a particular changeset from the "middle" of a
> set from one tree to another, without exporting it as a patch or
> rebuilding a new git tree.
Correct.
> If I export those two changesets as patches, and send them on.
> presumably I lose the changset comments etc.
Well, you can export them with "git send-email" and you won't be losing
any comments.
Alternatively, use "git cherry", which helps re-order the commits in your
tree. They'll be _new_ commits, but they'll have the contents moved over.
Junio, maybe you want to talk about how you move patches from your "pu"
branch to the real branches.
> and then when the upstream tree is merged back, it might look a little
> odd in the changeset history.
Well, you'll end up having the same change twice. It happens. Or if you
just redo your tree as a separate branch, you can reorder things so that
you don't have them twice at all.
> 2) There is no way to update the comment field of a changeset after it
> goes in (e.g. to add a bugzilla bug number for a bug that was opened
> just after the fix went in).
That's correct. Same things apply: you can move a patch over, and create a
new one with a modified comment, but basically the _old_ commit will be
immutable.
The good news is that it means that nobody else can change what you said
or did either.
> 3) There is no way to do a test commit of an individual changeset
> against a specified tree (to make sure it would still merge cleanly,
> automatically).
Oh, sure, that's certainly very possible, and the git cherry stuff even
helps you do it. Or use "git-apply --check" to just see if a patch
applies and do your own scripts.
Linus
^ 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