* Re: [PATCH] GIT commit statistics.
From: Martin Langhoff @ 2005-11-14 4:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkzr6gzz.fsf@assigned-by-dhcp.cox.net>
On 11/14/05, Junio C Hamano <junkio@cox.net> wrote:
> In your message you indicated that you use "format-patch" piped
> to "am". I think that is a better approach than "rebase" these
> days
Hmmm. But doesn't deal well with binary changes. We deal with a large
set of projects, and while we don't manage that many binary files, it
is just enough that I'll have to pass on only using format-patch.
> This was recently added by Linus to help git-merge do that:
>
> git-read-tree --trivial -m -u $O $A $B
Cool! Abusing that, perhaps I could teach git-rebase to take a
'--trivial-only' flag, and then cg-update --rebase could try
git-rebase --trivial-only, and fall back on cg-merge...
cheers,
martin
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Junio C Hamano @ 2005-11-14 3:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511131242p4692c74fn20c015998620b9f4@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On 11/13/05, Junio C Hamano <junkio@cox.net> wrote:
>> .... I
>> could do "git pull . origin" at this point, but that would
>> result in a useless mini-merge. My tree is not public so I can
>> freely rebase to clean things up.
>>
>> $ git rebase origin
>> $ git show-branch
>
> What happens if there are conflicts during git-rebase?
Well, obviously you could resolve them ;-). But if you are
rebasing just to reduce trivial mini-merges, it might make more
sense to honestly record the merge if the rebase involves
conflict resolution. After all, the reason rebase got conflicts
is because the development trail by somebody else that has been
already committed to the shared "master" branch overlapped what
you were doing in your "master" branch, isn't it?
In your message you indicated that you use "format-patch" piped
to "am". I think that is a better approach than "rebase" these
days; the conflict can be handled easier with that approach, and
if you use "--3way" flag you do not even have to worry about
patches in your branch that is already there in the shared
"master" (your "origin") branch.
So instead of running "git rebase origin" at this point, I may
do something like this [*1*]:
$ git-reset --hard origin
$ git-format-patch -k --stdout origin ORIG_HEAD | git am -3 -k
The first step rewinds my "master" (the original is stored in
ORIG_HEAD), and the second step extracts the commits that were
in my master but not in origin in a patch form, an replay them
on top of the "master" (which was rewound to "origin").
"git-am" would stop at the first unapplicable patch if there is
a conflict, leaving the conflicting patch in .dotest/patch.
I have to fix it up before going further. Here is how.
1. "git am" 3-way fallback would have kicked in, because I have
all the blobs the patch is supposed to apply to, and my
working tree and index is in a state just like when I am
resolving a conflicting merge after a pull. Clean up the
conflict in the working tree, build-test and all as usual.
2. Run "git diff HEAD >.dotest/patch" to record what the patch
should have been if it were to apply cleanly on top of the
previous state. If I did a noteworthy adjustment to the
patch, I might also edit .dotest/final-commit to update the
commit log message.
3. Then reset the working tree and index before the failed
application of this patch with "git reset --hard".
After that:
$ git am -3
would let me restart from that commit that did not replay well.
> Is there a cheap way to ask from a shell script whether the merge is
> truly trivial? I thought git-diff-tree would help me here, but it
> doesn't...
This was recently added by Linus to help git-merge do that:
git-read-tree --trivial -m -u $O $A $B
The command exits with a non-zero status, without touching index
nor working tree, when the merge is not "truly trivial".
Otherwise it does its thing -- the trivial in-index merge is
done, files in working tree updated and the only thing left for
you to do is to create a commit having parent $A and $B.
Would that help?
[Footnote]
*1* This is what the "make rebase restartable" comment in TODO
list is about, and I wanted to rewrite "rebase" to do exactly
these two commands, but I got distracted ;-).
^ permalink raw reply
* Re: [PATCH 5/5] -D <depth> option to recurse into merged branches
From: Eric Wong @ 2005-11-14 2:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git list
In-Reply-To: <20051112093208.GF16218@Muzzle>
One small fix on top of this one:
Don't check for parents if the only revision we have is a base-0
and @psets is empty.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-archimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 8a7e18ff0884cae74a1127d5c96577a85acca3f4
5f2896558284724bcc87eb64daa0933b544ec20d
diff --git a/git-archimport.perl b/git-archimport.perl
index a0ea016..b624ba6 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -186,7 +186,7 @@ sub do_abrowse {
if (%ps && !exists $psets{ $ps{id} }) {
my %temp = %ps; # break references
- if ($psets[$#psets]{branch} eq $ps{branch}) {
+ if (@psets && $psets[$#psets]{branch} eq $ps{branch}) {
$temp{parent_id} = $psets[$#psets]{id};
}
push (@psets, \%temp);
---
0.99.9.GIT
^ permalink raw reply related
* Re: http protocol, cloning git.git, fails (too many open files)
From: Junio C Hamano @ 2005-11-14 1:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051114010940.GQ30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Nov 14, 2005 at 01:42:33AM CET, I got a letter
> where wa1ter@myrealbox.com said that...
>>
>> So, what does cogito do differently that accounts for more open files?
>
> Cogito uses the same logic and underlying GIT fetching commands for
> cloning as well as for fetching,...
Ah, you are absolutely right. I've forgotten about that "dumb
http support" in git-clone.sh. That was done back when packs
were introduced but http-fetch was not told about them as a
stop-gap measure.
No wonder we do not see the same problem from git-clone. Thanks
for reminding me.
^ permalink raw reply
* Re: http protocol, cloning git.git, fails (too many open files)
From: Petr Baudis @ 2005-11-14 1:09 UTC (permalink / raw)
To: wa1ter; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511131625490.32662@x2.ybpnyarg>
Dear diary, on Mon, Nov 14, 2005 at 01:42:33AM CET, I got a letter
where wa1ter@myrealbox.com said that...
>
>
> On Sun, 13 Nov 2005, walt wrote:
>
> > On Sat, 2005-11-12 at 15:21 -0800, Junio C Hamano wrote:
> > [...]
> > > However, one thing puzzles me. I just tried to reproduce it by
> > > doing this:
> > >
> > > $ rm -fr git-http
> > > $ ulimit -n 16
> > > $ git clone http://www.kernel.org/pub/scm/git/git.git git-http
> > >
> > > and it did not fail on my Linux box...
>
> > I've never seen it on Linux...
>
> Aha! I do indeed see it on linux with ulimit -n 64 but *only* when I
> do the clone with cg-clone. When I use 'git clone' it works just fine.
>
> So, what does cogito do differently that accounts for more open files?
Cogito uses the same logic and underlying GIT fetching commands for
cloning as well as for fetching, while git-clone uses some custom logic
for cloning ("dumb http clone"). (In fact, is there a point in carrying
it further now that git-http-fetch got as smart as it got? You'll have
less code, and more importantly see bugs in the fetchers otherwise only
I see with Cogito. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Anyone using .git/branch-name?
From: Petr Baudis @ 2005-11-14 1:01 UTC (permalink / raw)
To: git
Hello,
is anyone using .git/branch-name? And if so, do you insist on keeping
using it? ;-) If noone speaks up in few days/weeks, I will remove its
traces from Cogito, since it was a silly idea in the first place and
I see no point in carrying it further.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: http protocol, cloning git.git, fails (too many open files)
From: wa1ter @ 2005-11-14 0:42 UTC (permalink / raw)
To: git
In-Reply-To: <1131926492.14637.5.camel@k9.localnet>
On Sun, 13 Nov 2005, walt wrote:
> On Sat, 2005-11-12 at 15:21 -0800, Junio C Hamano wrote:
> [...]
> > However, one thing puzzles me. I just tried to reproduce it by
> > doing this:
> >
> > $ rm -fr git-http
> > $ ulimit -n 16
> > $ git clone http://www.kernel.org/pub/scm/git/git.git git-http
> >
> > and it did not fail on my Linux box...
> I've never seen it on Linux...
Aha! I do indeed see it on linux with ulimit -n 64 but *only* when I
do the clone with cg-clone. When I use 'git clone' it works just fine.
So, what does cogito do differently that accounts for more open files?
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Thomas Matysik @ 2005-11-14 0:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511130942490.3263@g5.osdl.org>
Linus Torvalds wrote:
>
> Quite frankly, I'd really prefer to see the git-core-http as a separate
> package.
>
> I think it's ludicrous that people want to split out gitk (because it
> wants tcl/tk), but that we then add all of these really obscure
> dependencies for the http part.
Well, splitting out http occurred to me, but personally I don't have a
problem with installing expat (I'd need it eventually anyway) and I
figured anyone who did have a problem would say something. ;-)
The reason for this patch is that the RPM currently fails to build
without expat-dev.
The reason for wanting to split out gitk is that, for a machine where I
will never run gitk, I think the following dependency list is ludicrous:
fontconfig
freetype
tcl
tk
xorg-x11-Mesa-libGL
xorg-x11-libs
^ permalink raw reply
* Re: http protocol, cloning git.git, fails (too many open files)
From: walt @ 2005-11-14 0:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vmzk9e9km.fsf@assigned-by-dhcp.cox.net>
On Sat, 2005-11-12 at 15:21 -0800, Junio C Hamano wrote:
[...]
> However, one thing puzzles me. I just tried to reproduce it by
> doing this:
>
> $ rm -fr git-http
> $ ulimit -n 16
> $ git clone http://www.kernel.org/pub/scm/git/git.git git-http
>
> and it did not fail on my Linux box...
I've never seen it on Linux, but I do see it on NetBSD every time
with ulimit -n 64 (the default):
> Could you please try with the patch Nick posted (which covers
> less) and then with Pasky's patch?
Neither patch fixes the 'too many open files' error, but Pasky's
patch produces this debugging output:
[...]
progress: 46 objects, 105660 bytes
error: Couldn't create temporary
file .git/objects/ee/baf3aaffa72996ac8bdbc8e9498814cd99f506.temp
for .git/objects/ee/baf3aaffa72996ac8bdbc8e9498814cd99f506: Too many
open files
progress: 48 objects, 108247 bytes
error: fd leakage in release: 9
error: fd leakage in release: 11
error: fd leakage in release: 3
error: fd leakage in release: 13
error: fd leakage in release: 6
error: fd leakage in release: 12
error: fd leakage in release: 14
error: fd leakage in release: 8
error: fd leakage in release: 16
error: fd leakage in release: 15
error: fd leakage in release: 10
error: fd leakage in release: 5
error: fd leakage in release: 21
error: fd leakage in release: 17
error: fd leakage in release: 22
error: fd leakage in release: 19
error: fd leakage in release: 20
error: fd leakage in release: 25
error: fd leakage in release: 26
error: Could not read e8700aa756a3296ede4403db349dc64586935139
Waiting for
http://www.kernel.org/pub/scm/git/git.git/objects/dd/d5823df728bf213425533dcd2e47d61cbccf9e
cg-fetch: objects fetch failed
cg-clone: fetch failed
^ permalink raw reply
* Re: Balanced packing strategy
From: Junio C Hamano @ 2005-11-13 23:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Josef Weidendorfer
In-Reply-To: <200511132106.29841.Josef.Weidendorfer@gmx.de>
Petr Baudis <pasky@suse.cz> writes:
> This has the property that the second half of given pack is covered by
> objects with precision lower by one. This is a relatively high overload
> (this can be balanced by only keeping the last third or whatever), but
> it designed to reduce the overhead of fetching packs over dumb
> transport.
I have a feeling that you would be better off if instead do the
repacking on the server side to prepare multiple packs, each of
which has all the necessary objects to bring people who was
up-to-date at various timerange ago, to arrange that you would
need only one patch fetch with individual objects near the tip.
This obviously needs smarter client-side support.
Suppose we are somewhere after releasing v1.8 and inching
towards v1.9:
In your proposal, the object ranges each pack contains would
look like this:
v1.0..v1.5 --------
v1.5..v1.6 -----
v1.6..v1.7 -------
v1.7..v1.8 -----
individual objects ....
That is, there are slight overlaps but you would do multiple
packs if you are really behind.
Instead, you could do this:
v1.0..v1.8 ----------------------
v1.5..v1.8 --------------
v1.6..v1.8 ----------
v1.7..v1.8 ----
individual objects ....
Everybody starts from the tip, fetching individual objects, and
when the last repack boundary (the time we released 1.8) is
reached, the dumb protocol downloader now faces a choice. The
indices are fairly small, so you fetch all of them and see how
many objects you are lacking from each pack. If you were
up-to-date very long time ago, say at v1.2, you would obviously
need to fetch the longest pack. If you were up-to-date
recently, say after v1.6 was released, you need to fetch smaller
pack.
Given the self containedness requirements, any path that is
touched once in a period needs at least one full copy of it in
each pack (all other revisions could be deltified), and I
suspect in practice the oldest pack (v1.0..v1.5 pack in your
scheme) would not save much space by not having v1.5..v1.8
history. We could tweak things further to do something like
this:
v1.0..v1.8 ------------------
v1.5..v1.8 ----------
v1.6..v1.8 ------
v1.7..v1.8 ----
individual objects ....
to also account for a fact that the recent ones cover shorter
time range and not many paths are touched.
^ permalink raw reply
* Re: Git 0.99.9h
From: Junio C Hamano @ 2005-11-13 23:01 UTC (permalink / raw)
To: Adrien Beau; +Cc: git
In-Reply-To: <94fc236b0511131231u69f570c7ta083485694aa3a4@mail.gmail.com>
Adrien Beau <adrienbeau@gmail.com> writes:
> Is there a reason you did not release Git 0.99.9h? No package of any
> sort is available, and no announcement has been sent, as far as I
> know.
Sorry, just an interruption immediately before doing the final
moving of built packages into public space distracted me.
^ permalink raw reply
* Re: [PATCH] Building git on NetBSD
From: wa1ter @ 2005-11-13 22:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkzsc262.fsf@assigned-by-dhcp.cox.net>
On Sun, 13 Nov 2005, Junio C Hamano wrote:
> Date: Sun, 13 Nov 2005 01:44:37 -0800
> From: Junio C Hamano <junkio@cox.net>
> Cc: git@vger.kernel.org
> Newsgroups: gmane.comp.version-control.git
> Subject: Re: [PATCH] Building git on NetBSD
>
> Junio C Hamano <junkio@cox.net> writes:
>
> > Very well. Maybe LDFLAGS and ALL_LDFLAGS pair to parallel
> > CFLAGS and ALL_CFLAGS (the former is for the end user to
> > override from make command line, the latter is for Makefile to
> > augment and use)?
>
> Does this look OK?
<patch snipped>
Yes, git now compiles on NetBSD without modification and with no
warnings about unused linker flags. Thanks!
^ permalink raw reply
* Re: GIT character codecs
From: Marco Costalba @ 2005-11-13 20:52 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git@vger.kernel.org
Linus Torvalds wrote:
>
>On Sun, 13 Nov 2005, Marco Costalba wrote:
>
>>If encoding is a per-blob _and_ per-log message property a real solution, although cumbersone,
>>could be that git stores encoding togheter with the blob and the commits.
>
>
>We'd be much better off with just saying "we encourage people to use
>utf-8, but if you don't, just set your locale to make things show up
>properly".
>
>utf-8 is clearly the future, and if we make git internally aware of
>locales, that's just going to complicate things. And usually for no good
>reason, since users don't really care that much.
>
Yes, I agree with you and Junio, a workaround like let the user to choose the code page
in the viewer is more then enough.
And also in this case, a choice between the local codec and utf-8 should take almost
all cases.
Because of this, I added a text codec selector in qgit, reachable from settings menu.
There is a new release, qgit-0.97.2, with this new feature and some good
annotate fixes.
For the people interested the page with all the links is:
http://digilander.libero.it/mcostalba/
Marco
P.S: Now I can finally see Junio japanese name ;-)
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Linus Torvalds @ 2005-11-13 20:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4377A3E1.7070003@op5.se>
On Sun, 13 Nov 2005, Andreas Ericsson wrote:
>
> I *think* the ssh transport should work nicely over rsh as well. I don't have
> the slightest idea of where to find an rsh installation to test it with
> though.
You're right, it should be possible to just do a
export GIT_SSH=rsh
and things should just work.
But I don't have any machines that allow rsh either ;)
Linus
^ permalink raw reply
* Re: [PATCH] GIT commit statistics.
From: Martin Langhoff @ 2005-11-13 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy83s95k0.fsf@assigned-by-dhcp.cox.net>
On 11/13/05, Junio C Hamano <junkio@cox.net> wrote:
> Ah, the commit master~3 was what he had the last time I pulled
> from him, and since then he made a commit while I did three. I
> could do "git pull . origin" at this point, but that would
> result in a useless mini-merge. My tree is not public so I can
> freely rebase to clean things up.
>
> $ git rebase origin
> $ git show-branch
What happens if there are conflicts during git-rebase? I'm thinking of
adding an '-r' option to cg-update that will rebase instead of
merging, if the rebase is clean.
Is there a cheap way to ask from a shell script whether the merge is
truly trivial? I thought git-diff-tree would help me here, but it
doesn't...
martin
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Andreas Ericsson @ 2005-11-13 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511131137470.3263@g5.osdl.org>
Linus Torvalds wrote:
>
> If there's some way to "suggest" ssh when installing git, that would be
> good, but I don't think rpm has that.
It hasn't. It was designed to update software non-interactively.
> And if somebody doesn't have ssh
> installed, they probably don't have a network, so maybe even that is
> unnecessary.
>
I *think* the ssh transport should work nicely over rsh as well. I don't
have the slightest idea of where to find an rsh installation to test it
with though.
> So depending on the curl _program_ would fall under the same harmless case
> as depending on ssh and rsync, but the thing is, we depend on it as a
> library, which is why we should split things up.
>
True. But HTTP is a very simple protocol and git only uses a very small
portion of curl's capabilities so it wouldn't be rocket-science to hack
up some micro-replacement and always use the shipped stuff.
>
>>Moving out the {cvs,arch,svn}-import scripts made sense because they
>>were only faintly related to git day-to-day operations and forced some
>>really ridiculous dependencies down users throats (git requiring
>>subversion was a funny one...).
>
>
> Yes.
>
> NOTE! Git does actually require the "merge" program,
That depends on how it's used. If some script expects 'merge' to be
there and does things that might break the index if it isn't, then it's
required.
> which sometimes comes
> with the diff3 package, and more often comes with rcs. As with ssh and
> rsync, it's an external program and only really required if you do
> development (you can fast-forward something that you're only tracking
> read-only without it), so in theory you don't absolutely need it, but we
> do have a dependency on RCS right now due to that.
>
It could require /usr/bin/merge instead. Seeing as people who install
packages usually installs other things as packages too this would
probably make more sense.
> Which is a bit strange, and sometimes wrong (the same machine that doesn't
> have curl installed also doesn't have rcs installed, but I compile git on
> it anyway, and it works fine, since I use that machine only as a backup
> thing to receive git packs - in case kernel.org goes down _and_ all my
> home machines magically turn into pumpkins, I'll still have another site
> I can get my git repos from).
>
Still though, be kind to the fairy godmother. ;)
>
>>While we're on the subject of confusing; How about not naming non-core
>>packages git-core? It feels wrong to have git-core-http, git-core-cvs and
>>git-core-svn since they, strictly speaking, aren't required for core
>>operations.
>
>
> Yeah, that "git-core-xxx" thing is a bit strange, but on the other hand,
> it does make it clear that they all come from the same SRPM (the
> "git-core" SRPM) so in the end I think it's actually a good idea.
>
The change would only mean that all packages will come from the "git"
SRPM rather than the "git-core" SRPM so this point is moot unless there
will ever be such a thing as the "git" SRPM to contend with (which will
be less likely if we're it, so to speak).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Balanced packing strategy
From: Josef Weidendorfer @ 2005-11-13 20:06 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Craig Schlenter
In-Reply-To: <20051112135947.GC30496@pasky.or.cz>
On Saturday 12 November 2005 14:59, Petr Baudis wrote:
> The repacking should be done in such a way to minimize the overhead for
> the dumb transport users. Ideal for this is some structure like (at the
> end of october):
>
> year2003.pack
> year2004.pack
> ...
> week42.pack
> week43.pack
> <individual objects for weeks 43, 44>
I am not sure if it is really beneficial, as packs have the requirement
to be self contained, so you get a lot of objects undeltified which could
be deltified in a better scheme (as eg. in git native protocol).
AFAICS, the git native protocol (which is nothing more than a pack itself
for each transfer) even has this problem, too: If you are updating every
day via git native, the sum of transfered bytes in a month will be a
multiple of one git transfer for all the month's changes.
To keep the pack self-containment property, but work better with dumb
transfers, we could introduce incremental packs:
Instead of fully repacking, create a new pack by only appendending new
objects at the end of the pack. Thus, most objects will be appended in
deltified form, making the incremental addition quite small. The outcome
would be a totally new package.
Unfortunately, I do not know the package format in detail, and hope that
this is possible at all.
For dumb protocols to take advantage of this, the information that the
first part of a package is actually the same as another package has to
be stored somewhere visible.
If a client detects that it has the first part of a pack already locally,
it would be enough to fetch only some the second part.
This is more or less the same as Pasky's solution, but by using incremental
packs instead. I think that such incremental packing will not even take
much more space that fully repacking.
Josef
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Linus Torvalds @ 2005-11-13 19:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437788A0.6030103@op5.se>
On Sun, 13 Nov 2005, Andreas Ericsson wrote:
>
> This would get rid of expat and curl dependencies. ssh, rsync and git
> protocols use external programs so they aren't exactly required (from the rpm
> point of view anyways, they'll just fail if rsync or ssh isn't installed).
Actually, the "git://" protocol (and local filesystem ones) doesn't need
any external programs. So if you just want to follow another repository,
you can do so even without ssh or rsync installed.
But yes, the nice thing about ssh(+git):// and rsync:// is that since we
don't link against them or depend on them in general, you can certainly
install git without having them, and don't need to make a dependency of
it.
If there's some way to "suggest" ssh when installing git, that would be
good, but I don't think rpm has that. And if somebody doesn't have ssh
installed, they probably don't have a network, so maybe even that is
unnecessary.
So depending on the curl _program_ would fall under the same harmless case
as depending on ssh and rsync, but the thing is, we depend on it as a
library, which is why we should split things up.
> Moving out the {cvs,arch,svn}-import scripts made sense because they
> were only faintly related to git day-to-day operations and forced some
> really ridiculous dependencies down users throats (git requiring
> subversion was a funny one...).
Yes.
NOTE! Git does actually require the "merge" program, which sometimes comes
with the diff3 package, and more often comes with rcs. As with ssh and
rsync, it's an external program and only really required if you do
development (you can fast-forward something that you're only tracking
read-only without it), so in theory you don't absolutely need it, but we
do have a dependency on RCS right now due to that.
Which is a bit strange, and sometimes wrong (the same machine that doesn't
have curl installed also doesn't have rcs installed, but I compile git on
it anyway, and it works fine, since I use that machine only as a backup
thing to receive git packs - in case kernel.org goes down _and_ all my
home machines magically turn into pumpkins, I'll still have another site
I can get my git repos from).
> While we're on the subject of confusing; How about not naming non-core
> packages git-core? It feels wrong to have git-core-http, git-core-cvs and
> git-core-svn since they, strictly speaking, aren't required for core
> operations.
Yeah, that "git-core-xxx" thing is a bit strange, but on the other hand,
it does make it clear that they all come from the same SRPM (the
"git-core" SRPM) so in the end I think it's actually a good idea.
Linus
^ permalink raw reply
* [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
From: Paolo 'Blaisorblade' Giarrusso @ 2005-11-13 19:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I just got a "removal vs. changed" conflict, which is unhandled by StGit. That
is taken from git-merge-one-file resolver, but is bad, as stg resolved does not
handle unmerged entries (and probably it should be fixed too).
Sample patch included, but some thought must be done on it (see the comments I
left in).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
gitmergeonefile.py | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/gitmergeonefile.py b/gitmergeonefile.py
index 1cba193..9344d33 100755
--- a/gitmergeonefile.py
+++ b/gitmergeonefile.py
@@ -180,6 +180,30 @@ if orig_hash:
os.remove(path)
__remove_files()
sys.exit(os.system('git-update-index --remove -- %s' % path))
+ # file deleted in one and changed in the other
+ else:
+ # Do something here - we must at least merge the entry in the cache,
+ # instead of leaving it in U(nmerged) state. In fact, stg resolved
+ # does not handle that.
+
+ # Do the same thing cogito does - remove the file in any case.
+ os.system('git-update-index --remove -- %s' % path)
+
+ #if file1_hash:
+ ## file deleted upstream and changed in the patch. The patch is
+ ## probably going to move the changes elsewhere.
+
+ #os.system('git-update-index --remove -- %s' % path)
+ #else:
+ ## file deleted in the patch and changed upstream. We could re-delete
+ ## it, but for now leave it there - and let the user check if he
+ ## still wants to remove the file.
+
+ ## reset the cache to the first branch
+ #os.system('git-update-index --cacheinfo %s %s %s'
+ #% (file1_mode, file1_hash, path))
+ __conflict()
+
# file does not exist in origin
else:
# file added in both
^ permalink raw reply related
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Andreas Ericsson @ 2005-11-13 18:40 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511130942490.3263@g5.osdl.org>
Linus Torvalds wrote:
>
> Quite frankly, I'd really prefer to see the git-core-http as a separate
> package.
>
This would get rid of expat and curl dependencies. ssh, rsync and git
protocols use external programs so they aren't exactly required (from
the rpm point of view anyways, they'll just fail if rsync or ssh isn't
installed). I.e. Good idea, but see below.
> I think it's ludicrous that people want to split out gitk (because it
> wants tcl/tk), but that we then add all of these really obscure
> dependencies for the http part.
>
Couldn't agree more. Moving out the {cvs,arch,svn}-import scripts made
sense because they were only faintly related to git day-to-day
operations and forced some really ridiculous dependencies down users
throats (git requiring subversion was a funny one...).
It *might* make sense to build a very minimalistic package for
server-side use only, but for client-side use it's really only confusing
to have a dozen packages to install to get the full functionality.
While we're on the subject of confusing; How about not naming non-core
packages git-core? It feels wrong to have git-core-http, git-core-cvs
and git-core-svn since they, strictly speaking, aren't required for core
operations.
So, to be nicely constructive then I suggest we create the following
packages;
git-core; Low-level stuff with as few dependencies as possible (ssh and
openssl should suffice, really). This should be everything needed for
running a server and should be required by all other git-* packages. It
will most likely be enough to run most client-side things as well.
git; holds all client side stuff useful for humans interfacing with git
that introduces "normal" dependencies not necessarily found everywhere
(gitk and suchlike).
git-email; This one only uses Email::Valid->address(), so I'll import
that function from the perl module so this dependency can be dropped and
git-send-email can be in the 'git' package.
Programs introducing obscene or plain weird dependencies (cvsimport,
svnimport) can be put into their own package, but we should really try
to keep those extra packages to a minimum and simply force users who
want all the fluffy niceties of the 'git' package to install whatever's
required (or install with --nodeps, or from source, or...).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: GIT character codecs
From: Linus Torvalds @ 2005-11-13 17:51 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <20051113081443.38296.qmail@web26309.mail.ukl.yahoo.com>
On Sun, 13 Nov 2005, Marco Costalba wrote:
>
> If encoding is a per-blob _and_ per-log message property a real solution, although cumbersone,
> could be that git stores encoding togheter with the blob and the commits.
We'd be much better off with just saying "we encourage people to use
utf-8, but if you don't, just set your locale to make things show up
properly".
utf-8 is clearly the future, and if we make git internally aware of
locales, that's just going to complicate things. And usually for no good
reason, since users don't really care that much.
I really hate codepages. I'd much rather say:
- git is 8-bit clean, so you can use any damn encoding you want
- utf-8 is strongly recommended for all the same reasons it's recommended
for anything else.
Hmm?
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Add expat and expat-devel dependencies (for http-push) to RPM spec.
From: Linus Torvalds @ 2005-11-13 17:46 UTC (permalink / raw)
To: Thomas Matysik; +Cc: git
In-Reply-To: <4376C797.3050600@matysik.co.nz>
Quite frankly, I'd really prefer to see the git-core-http as a separate
package.
I think it's ludicrous that people want to split out gitk (because it
wants tcl/tk), but that we then add all of these really obscure
dependencies for the http part.
There are probably more boxes with tcl/tk on them than there are boxes
with curl and expat (on one box I use, I already have to compile with
NO_CURL=1 to avoid getting the http programs.
Linus
^ permalink raw reply
* Re: git-merge-recursive: documentation and implementation notes
From: Fredrik Kuivinen @ 2005-11-13 17:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, git
In-Reply-To: <20051112210306.GG30496@pasky.or.cz>
On Sat, Nov 12, 2005 at 10:03:06PM +0100, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Sat, Nov 12, 2005 at 09:34:57PM CET, I got a letter
> where Fredrik Kuivinen <freku045@student.liu.se> said that...
> > Lets assume there is a merge conflict when we merge B and C in the
> > criss-cross case above. Then both D and E must resolve this
> > conflict. If they have done it in the same way we wont get a merge
> > conflict at M, if they have resolved it differently we will get a
> > merge conflict. In the first case there is no merge conflict at M, in
> > the second case the user has to pick which one of the two different
> > resolutions she wants.
> >
> > Note that the algorithm will happily write non-clean merge results to
> > the object database during the "merge common ancestors" stage. Hence,
> > when we are merging B and C "internally" we will _not_ ask the user to
> > resolve any eventual merge conflicts.
>
> I find this part somewhat unclear. So how does the user pick which of
> the two different resolution she wants if we will not ask the user to
> resolve any conflicts?
>
If we have a conflict when we merge B and C we will get a file with
conflict markers from merge(1) in it, so it will look something like
1
2
3
<<<<<<
4
5
======
6
7
>>>>>>
8
9
This file will be stored in the object database and the temporary tree
which is created by the merge of B and C will refer to it.
The algorithm will then merge D and E and use the file above as the
common ancestor. There are now two cases to consider, the first one is
that both D and E resolve the conflict above in the same way (and
possible make other changes which can be cleanly merged), we end up
with something like
1
2
3
4
5
8
9
in both D and E. This will be merged cleanly into M. The other case is
that D and E either resolves the conflict differently or that they do
other modifications which aren't possible to merge automatically. In
this case we will let the user do the conflict resolution.
So, what I meant was that during the first merge, of B and C, the user
do not have to do anything with any eventual conflicts. However, in
the top-level merge, conflict resolution works in the same way as it
does for the 'resolve' strategy, i.e., the output of merge(1) is
stored in the working directory and the index is updated to make 'git
diff' useful.
- Fredrik
^ permalink raw reply
* [PATCH] Remove git-rename. git-mv does the same
From: Josef Weidendorfer @ 2005-11-13 14:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
We have git-mv now since quite some time, and it does all which
git-rename did, as it is derived from it. Even if you want to
keep git-rename, it should be a symlink to git-mv instead.
.gitignore | 1 -
Documentation/git-rename.txt | 32 -------------------
Documentation/git.txt | 3 --
Makefile | 2 +
git-rename.perl | 70 ------------------------------------------
5 files changed, 1 insertions(+), 107 deletions(-)
delete mode 100644 Documentation/git-rename.txt
delete mode 100755 git-rename.perl
applies-to: e915ab830dbf42430138b4542278097d16f9f2f1
9a06e0c0981cae2417e4355ae7220f1e4bae5e85
diff --git a/.gitignore b/.gitignore
index 328b399..26398b3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,7 +74,6 @@ git-read-tree
git-rebase
git-receive-pack
git-relink
-git-rename
git-repack
git-request-pull
git-reset
diff --git a/Documentation/git-rename.txt b/Documentation/git-rename.txt
deleted file mode 100644
index 583cb03..0000000
--- a/Documentation/git-rename.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-git-rename(1)
-=============
-
-NAME
-----
-git-rename - Script used to rename a file, directory or symlink.
-
-
-SYNOPSIS
---------
-'git-rename' <source> <destination>
-
-DESCRIPTION
------------
-This script is used to rename a file, directory or symlink.
-
-The index is updated after successful completion, but the change must still be
-committed.
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org>
-Rewritten by Ryan Anderson <ryan@michonline.com>
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the gitlink:git[7] suite
-
diff --git a/Documentation/git.txt b/Documentation/git.txt
index a9d47c1..62c8ce7 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -262,9 +262,6 @@ gitlink:git-push[1]::
gitlink:git-rebase[1]::
Rebase local commits to new upstream head.
-gitlink:git-rename[1]::
- Rename files and directories.
-
gitlink:git-repack[1]::
Pack unpacked objects in a repository.
diff --git a/Makefile b/Makefile
index 514ab60..24884ab 100644
--- a/Makefile
+++ b/Makefile
@@ -94,7 +94,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-rename.perl git-shortlog.perl git-fmt-merge-msg.perl \
+ git-shortlog.perl git-fmt-merge-msg.perl \
git-svnimport.perl git-mv.perl git-cvsexportcommit.perl
SCRIPT_PYTHON = \
diff --git a/git-rename.perl b/git-rename.perl
deleted file mode 100755
index 3b1127b..0000000
--- a/git-rename.perl
+++ /dev/null
@@ -1,70 +0,0 @@
-#!/usr/bin/perl
-#
-# Copyright 2005, Ryan Anderson <ryan@michonline.com>
-#
-# This file is licensed under the GPL v2, or a later version
-# at the discretion of Linus Torvalds.
-
-
-use warnings;
-use strict;
-
-sub usage($);
-
-# Sanity checks:
-my $GIT_DIR = $ENV{'GIT_DIR'} || ".git";
-
-unless ( -d $GIT_DIR && -d $GIT_DIR . "/objects" &&
- -d $GIT_DIR . "/objects/" && -d $GIT_DIR . "/refs") {
- usage("Git repository not found.");
-}
-
-usage("") if scalar @ARGV != 2;
-
-my ($src,$dst) = @ARGV;
-
-unless (-f $src || -l $src || -d $src) {
- usage("git rename: bad source '$src'");
-}
-
-if (-e $dst) {
- usage("git rename: destinations '$dst' already exists");
-}
-
-my (@allfiles,@srcfiles,@dstfiles);
-
-$/ = "\0";
-open(F,"-|","git-ls-files","-z")
- or die "Failed to open pipe from git-ls-files: " . $!;
-
-@allfiles = map { chomp; $_; } <F>;
-close(F);
-
-my $safesrc = quotemeta($src);
-@srcfiles = grep /^$safesrc/, @allfiles;
-@dstfiles = @srcfiles;
-s#^$safesrc(/|$)#$dst$1# for @dstfiles;
-
-rename($src,$dst)
- or die "rename failed: $!";
-
-my $rc = system("git-update-index","--add","--",@dstfiles);
-die "git-update-index failed to add new name with code $?\n" if $rc;
-
-$rc = system("git-update-index","--remove","--",@srcfiles);
-die "git-update-index failed to remove old name with code $?\n" if $rc;
-
-
-sub usage($) {
- my $s = shift;
- print $s, "\n" if (length $s != 0);
- print <<EOT;
-$0 <source> <dest>
-source must exist and be either a file, symlink or directory.
-dest must NOT exist.
-
-Renames source to dest, and updates the git cache to reflect the change.
-Use "git commit" to make record the change permanently.
-EOT
- exit(1);
-}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Bugfix: stop if directory already exists
From: Josef Weidendorfer @ 2005-11-13 14:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Fix a typo: We do not want to run the directory as command,
and want to terminate if the directory exists
Additionally, update the usage message
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
Regarding the usage: I do not think that on an error condition
the usage string should be outputted. This helps nothing:
either the user knows the usage, and can see what is wrong by
the error message, or he should look up the man page.
Should we use "git clone" or "git-clone" in the usage message?
Or perhaps
usage: git clone ...
For more details, see 'man git-clone'
?
git-clone.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 62fad3f1275b9bbf07fba50c328a3bd730c3454c
3de065bff303bd4caa433dfa685fdc1164be2b81
diff --git a/git-clone.sh b/git-clone.sh
index f99e0ad..c09979a 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "* git clone [-l [-s]] [-q] [-u <upload-pack>] [-n] <repo> <dir>"
+ echo >&2 "* git clone [-l [-s]] [-q] [-u <upload-pack>] [-n] <repo> [<dir>]"
exit 1
}
@@ -98,7 +98,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*/||g')
-[ -e "$dir" ] && $(echo "$dir already exists."; usage)
+[ -e "$dir" ] && echo "$dir already exists." && usage
mkdir -p "$dir" &&
D=$(
(cd "$dir" && git-init-db && pwd)
---
0.99.9.GIT
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox