* Re: Comments on recursive merge..
From: Linus Torvalds @ 2005-11-11 22:53 UTC (permalink / raw)
To: Junio C Hamano, Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <7v4q6ilt3m.fsf@assigned-by-dhcp.cox.net>
On Fri, 11 Nov 2005, Junio C Hamano wrote:
>
> Some observations.
>
> - Trivial Merges count is surprisingly high. About 1/3 of
> merges are pure in-index merges.
I actually don't think that is surprisingly high, and would actually have
expected it to be closer to 50%.
On the other hand, the merges that end up being pure fast-forwards aren't
counted as merges at all (since they don't show up as commits), so maybe
that's what skews my preception of a big percentage of merges as being
really trivial.
> - Most of the commits (developer commits, not merges) are
> small and touches only a couple of paths.
This is something where I think the kernel is perhaps unusual, especially
for a big project. We really do encourage people to make lots of small and
well-defined changes, and the whole flow of development has been geared
towards it.
> - Nobody does octopus ;-).
I do think octopus is really cool, and still think seeing that five-way
octopus-merge in gitk in the git history was really really cool.
It doesn't look as good any more, btw: do "gitk" on the current git tree,
and search for "Octopus merge", and you'll see some of the history lines
crossing each other. Paul?
But yeah, it's a pretty special thing. I think its coolness factor way
outweighs its usefullness factor ;^p
> - We did not have multi-base merge case during the period
> looked at (but the sample count is very low).
Again, this is possibly because the kernel has already had a few years of
distributed SCM usage under its belt, and we've tried to not only merge
in a timely manner, but also try to keep history reasonably clean and not
have a lot of cross-merging back and forth. That cuts down on multi-base
possibilities.
> - merge-one-file was called for only a handful (median 8)
> files, which is negligibly small compared to the total 17K
> files in the kernel tree, and fairly small compared to the
> number of changed paths from the first parent (meaning,
> read-tree trivial collapsing helped majorly). Among them,
> the number of paths that needed real file-level 3-way merges
> were even smaller (avg 1.96).
I definitely think this is true for any big project.
Small projects will inevitably have changes that modify large portions of
the source base. But with small projects, it doesn't really matter _what_
you do, you can do it fast.
Big projects (at least the sane kind) will never have lots of changes that
modify a very big percentage of the source-tree. It's just too painful
(and I'm not talking from a SCM angle, just from a developer angle).
> All three of these points together is a fine demonstration
> that you designed git really right.
Well, it's self-re-inforcing. It was designed for the kernel usage
patterns, so using the kernel to confirm that it's the "right design" is a
bit self-serving. Sure, it's a good sign that my mental model of what the
usage patters are does actually match reality, but at the same time it
might be more interesting to see if other projects that use git end up
using it the same way and/or have different statistics.
I do expect that the size of the project will impact the statistics a lot.
Linus
^ permalink raw reply
* Re: Something looks like CVS modules
From: Josef Weidendorfer @ 2005-11-11 22:40 UTC (permalink / raw)
To: git
In-Reply-To: <20051111212953.GX30496@pasky.or.cz>
On Friday 11 November 2005 22:29, Petr Baudis wrote:
> Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter
> where Alexander Litvinov <lan@ac-sw.com> said that...
>
> Aha. So it isn't so much about modules, but more about nested checkouts,
> described in Cogito's TODO as:
>
> * Subprojects
> ...
Interesting. So these would be multiple git repositories, which are
more or less loosely coupled via same head and tag names?
Instead of putting multiple git repositories in subdirectories,
these possibly could be combined into one .git/ with different index
files, and simultaneously checked out files. This way, the
partitioning of files does not have to follow directory boundaries
(similar to the "todo" branch of git itself).
We would need a configuration for the partitioning.
E.g. a .git/projects
gitk: gitk
todo: TODO TODO-docu
docu: Documentation/*
git: *
(perhaps with path remapping between checkout files and paths in the
git tree objects of every subproject, to be flexible)
You would have multiple indexes: .git/index.gitk, .git/index.todo...
.git/HEAD would have to hold multiple references for the currently
checked out subprojects:
gitk: refs/gitk/heads/master
git: refs/git/heads/master
On commiting, the subproject partitions are checked seperatly for
changes, and commits objects are done for each subproject.
Fetching/merging is done on each subproject of its own.
You probably want to have multi-head tags covering all subprojects.
And for a more tight coupling of subprojects, you probably even want
to have multihead commits every time a commit is done in one subproject,
which leads to branches tracking the versioning of all subprojects,
i.e. multihead heads ;-)
I think that even subprojects of subprojects fall out naturally.
I am quite sure this can be done in a fully compatible way to Git-1:
with Git-1, you have only one subproject, the empty one.
It should be possible to combine multiple Git-1 repositories to a
repository with multiple subprojects, where each subproject was its
own project with Git-1.
Josef
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Junio C Hamano @ 2005-11-11 22:39 UTC (permalink / raw)
To: Petr Baudis, Daniel Barkalow; +Cc: git
In-Reply-To: <20051111215620.GX16061@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> 16 anc1/anc2 anc1 anc2 no merge
>
> What ends up in the index at this moment as "stage 1"? anc1? anc2?
> Two stage 1 entries? And what does git-merge-index do about this?
I think we decided there is no single sensible resolution, and
we leave stage 1 empty.
Come to think of it, we should signal that we are punting by
either exiting non-zero, or stuffing 0{40} SHA1 in stage1, so
that we can distinguish the case with two sides adding things
differently. Daniel, what do you think?
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-11 22:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511071629270.3247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> Another thing to consider is if it is fast enough for everyday
>> trivial merges.
>
> Hmm. True. The _really_ trivial in-index case triggers for me pretty
> often, but I haven't done any statistics. It might be only 50% of the
> time.
Just for fun, I randomly picked two heads/master commits from
linux-2.6 repository (one was when I happened to have pulled the
last time, and the other was when I thought this might be an
interesting exercise and pulled again), and fed the commits
between the two to a little script that looks at commits and
tries to stat what they did (the script ignores renames so they
appear as deletes and adds).
Here is what the script spitted out:
Total commit objects: 3957
Trivial Merges: 72 (1.82%)
Merges: 225 (5.69%)
Number of paths touched by non-merge commits:
average 4.50, median 2, min 2, max 199
Number of merge parents:
average 2.00, median 2, min 2, max 2
Number of merge bases:
average 1.00, median 1, min 1, max 1
File level merges:
average 37.61, median 8, min 0, max 555
Number of changed paths from the first parent:
average 379.09, median 66, min 1, max 7553
File level 3-ways:
average 1.96, median 1, min 0, max 37
Paths deleted:
average 47.56, median 15, min 0, max 554
This counts what happened in individual devleoper's trees,
subsystem maintainer trees and your tree, not just what you saw
yourself.
Some observations.
- Trivial Merges count is surprisingly high. About 1/3 of
merges are pure in-index merges.
- Most of the commits (developer commits, not merges) are
small and touches only a couple of paths.
- Nobody does octopus ;-).
- We did not have multi-base merge case during the period
looked at (but the sample count is very low).
- merge-one-file was called for only a handful (median 8)
files, which is negligibly small compared to the total 17K
files in the kernel tree, and fairly small compared to the
number of changed paths from the first parent (meaning,
read-tree trivial collapsing helped majorly). Among them,
the number of paths that needed real file-level 3-way merges
were even smaller (avg 1.96).
All three of these points together is a fine demonstration
that you designed git really right.
The samples were between these two commits:
commit 6693e74a16ef563960764bd963f1048392135c3c
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Tue Oct 25 20:40:09 2005 -0700
commit 388f7ef720a982f49925e7b4e96f216f208f8c03
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date: Fri Nov 11 09:26:39 2005 -0800
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Petr Baudis @ 2005-11-11 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1nni78.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Nov 11, 2005 at 07:38:19PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> > Yes, but what I didn't find out is whether the additional trees result
> > in additional stages, what are the trivial merging rules, how does it
> > play together with git-merge-index, etc. Doesn't seem to be documented
> > either.
>
> Documentation/technical/ perhaps?
This contains the merge resolution tables, which is very useful - thanks
for that.
However, it still doesn't seem to answer my question - do the additional
trees result in additional stages? Let's take e.g.:
16 anc1/anc2 anc1 anc2 no merge
What ends up in the index at this moment as "stage 1"? anc1? anc2?
Two stage 1 entries? And what does git-merge-index do about this?
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: Something looks like CVS modules
From: Petr Baudis @ 2005-11-11 21:29 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200511111713.58018.lan@ac-sw.com>
Dear diary, on Fri, Nov 11, 2005 at 12:13:57PM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> On Friday 11 November 2005 16:58, Petr Baudis wrote:
> > But this is troublesome, and doesn't fit into GIT's model at all. Do you
> > have any concrete example of a scenario where something like this would
> > be useful?
>
> For eaxmle: I have java lib A. I setup project B in this way:
> B/src/
> B/A/src
>
> Have another project C:
> C/src/
> C/A/src
>
> Both of them share the same code from library's module. I can tag them, edit,
> commit: do all work I usualy do. If I change something in B/A/src this will
> be updated into C/A/src.
Aha. So it isn't so much about modules, but more about nested checkouts,
described in Cogito's TODO as:
* Subprojects
Support a GIT project inside a GIT project:
x/.git
x/foo/bar/.git
x/foo/bar/baz/.git
x/quux/zot/.git
That means cg-update working recursively and cg-add'n'stuff
checking if there isn't another .git along the path of its
argument.
Needs more thought, especially wrt. fetching and merging
recursive semantics.
Yes, that would be nice - it is something that you get kind of for-free
in CVS given its internal architecture, but needs specially crafted
support in the GIT environment. But when thinking about it (and we
discussed it with Jonas during one night bike ride through Copenhagen
some time ago ;), most of the problems with fetching and merging
semantics turn out to be actually largely artificial, and just doing
the intuitively right thing should be ok.
Patches welcome. Otherwise, I will get to it, but not very fast. :-)
--
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: [ANNOUNCE] GIT 0.99.9g
From: H. Peter Anvin @ 2005-11-11 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>May I *STRONGLY* urge you to name that something different.
>>"lost+found" is a name with special properties in Unix; for example,
>>many backup solutions will ignore a directory with that name.
>
>
> Yeah, the original proposal (in TODO list) explicitly stated why
> I chose lost-found instead of lost+found back then, and somebody
> on the list (could have been Pasky but I may be mistaken) said
> not to worry. In any case, if we go the route Daniel suggests,
> we would not be storing anything on the filesystem ourselves so
> this would be a non-issue.
>
Just realized one more issue with this... a lot of non-Unix filesystems
can't deal with files with a + sign.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: H. Peter Anvin @ 2005-11-11 21:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437392AD.20906@op5.se>
Andreas Ericsson wrote:
>>
>> It's nice in concept, but I think there are a lot of reasons why this
>> is a bad idea:
>>
>> - "man" doesn't handle it. It would be another thing if "man" could
>> be taught to understand commands like "man cvs checkout" or "man git
>> fetch".
>
> This is moot. man-pages can still be named git-fetch.
>
Yes, of course, but that requires the user to be aware of yet another
program-specific convention. I do believe that supporting hierarchial
man pages would be a good thing, but one has to start that in the proper
point.
>> - There is no general way to teach shells etc about it, for tab
>> completion etc.
>
> Add the lib directory to the path (for git-<tab><tab>) or have it
> auto-evaluate the result of a git command-listing.
... which means the end user has to do something specific to their
environment.
All in all, I think the negatives outweigh the positives.
-hpa
^ permalink raw reply
* [PATCH] Reference technical/trivial-merge.txt in git-read-tree documentation
From: Petr Baudis @ 2005-11-11 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
That file, with the so valuable (and so confusing) tables describing
the precise resolution rules git-read-tree follows, silently sat in
the corner and almost noone knew about it (well, I didn't, at least).
This references it from the git-read-tree documentation, so that there
is some chance that interested people will find it.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-read-tree.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 7db5fb5..ff17bad 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -55,6 +55,12 @@ merge, a single tree merge if only 1 tre
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
provided.
+The detailed listing of the precise automatic resolution rules
+git-read-tree follows can be found in 'technical/trivial-merge.txt'.
+It is in part redundant with what you will find below since the
+fellow documenters cannot decide which of the descriptions is more
+confusing and remove the other one.
+
Single Tree Merge
~~~~~~~~~~~~~~~~~
^ permalink raw reply related
* [ANNOUNCE] Cogito-0.16rc1
From: Petr Baudis @ 2005-11-11 20:24 UTC (permalink / raw)
To: git
Hello,
I'm announcing the release of Cogito version 0.16rc1, the human-friendly
version control UI for Linus' GIT tool. Share and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
Tons of new features are balanced by other tons of bugfixes, but since
there was a lot of stuff, I would like to give it a while to stabilize,
so that 0.16 itself is really stable. Therefore, I will run this through
the rc process. (Note that 0.16rc1 was tagged the last night, and few
more stuff already landed into git since then, but nothing critical.)
I'm not sure if many people will actually use the rc releases (I guess
they are either following stable releases or the latest version from
git), but at least it's an anchor point for me - from now on, I will
keep a stable branch in parallel with the development branch (or rather,
I will fork out the development branch when I'm about to do any major
change), so the bugfixes will get back to the latest stable version,
and I won't feel that bad about not releasing for so long.
The notable new stuff includes:
* Significant fetching surgery:
- host:path location now means git+ssh instead of rsync (but it
is deprecated in favour of explicit protocol name - safer and
less confusing for you)
- git+ssh uses packed transport instead of the dated git-ssh-fetch
- Tags fetching is now much more reliable, saner and faster
- More robust rsync fetching (for anyone actually still using it)
- Speedup of the whole thing (the progressbar was actually slowing
the process down so much that I'm almost afraid to say it)
* The one-file merging autoresolver covers much more cases now;
it still probably doesn't handle file-symlink and file-directory
conflicts (actually, I didn't even test anything related to that
yet), but otherwise it should handle pretty much any conflict now
(except that it yet won't make sure that you resolved the conflict
before committing)
* New command cg-admin-setuprepo for creating public repositories
* Major cg-restore surgery - more pleasant to use, more powerful,
more robust
* cg-push -t will push tags
* cg-merge -j will join projects with disjoint histories
* cg-merge --squash will do the "squash merge" (see docs for details)
* cg-log --summary will show the shortlog output
* cg-diff -s will show diffstat
* cg-reset --adds-removes will reset only index (cancel the
adds/removes recorded, from the user perspective)
* cg-status DIRNAME will show the status relative to that directory
* cg-status -s will filter for only the given status flags
* cg-tag always creates the tag object
* First draft of the VCS-neutral interface implemented as
contrib/neutral.sh
* Speedups all around (e.g. per-file cg-log SIXTY times)
* Reorganized cg-help output
* More new tests in the testsuite
* Documentation stuff - the "scripted tutorial", README expanded,
tiny stuff all around
* Heaps of both major and minor bugfixes; I won't name them, you can
look at "cg-log -s -r cogito-0.15.1.." - but you should definitely
upgrade, at last when the stable 0.16 comes out
P.S.: See us at #git @ FreeNode!
Happy hacking,
--
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: [PATCH] C implementation of the 'git' program.
From: Junio C Hamano @ 2005-11-11 19:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <437488E6.2050100@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Thoughts? I've got a feeling I've overlooked something here.
If you are doing it, it might make sense to include it from
Makefiles in subdirectories, so that on a platform with non GNU
tar, you could say:
$ cd t
$ make
and get TAR=gtar definition from ../config.mk
I think Smurf's libize repository has something like that; it is
found at:
$ cat .git/remotes/smurf
URL: http://netz.smurf.noris.de/git/git.git
Pull: libize:libize
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Junio C Hamano @ 2005-11-11 19:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4373CEA8.1020900@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Linus Torvalds wrote:
>
>> I think this might be a bit ambiguous. When I see "GIT_LIB", to me
>> it implies traditional libraries (ie a "libgit.a" kind of thing),
>> not the kind of "git executable plugin" directory.
>> So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a
>> "--libexec" kind of flavor, if only to avoid that confusion.
>
> Someone said libexec was moving out (of Linux, at least), so I thought
> I'd better avoid that. Perhaps GIT_LIBDIR?
More like "the rest of git executables". GIT_EXEC_PATH, with
"git --exec-path" command, perhaps?
^ permalink raw reply
* Re: merge-recursive: include heapq?
From: Junio C Hamano @ 2005-11-11 19:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051111185246.GB13524@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Johannes Schindelin, Fri, Nov 11, 2005 15:23:04 +0100:
>> I get this when pulling:
>>...
>> Okay, my python is *old*:
>>
>> $ python -V
>> Python 2.2.1
>>
>> Is it worthwhile to include heapq as we did with subprocess? Or should I
>> upgrade...
>
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Traceback (most recent call last):
> File "/home/raa/bin/git-merge-recursive", line 8, in ?
> from gitMergeCommon import *
> File "/home/raa/share/git-core/python/gitMergeCommon.py", line 14, in ?
> import subprocess
> ImportError: No module named subprocess
> Automatic merge failed/prevented; fix up by hand
>
> That said, I thought an upgrade was worth it and upgraded my 2.3 to 2.4 :)
Something like this is needed, I suppose...
-- >8 -- cut here -- >8 --
INSTALL: duplicate python requirements from Makefile
and refer the reader to Makefile for other things that can be
tweaked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git diff
diff --git a/INSTALL b/INSTALL
index 06b11e1..63ccf62 100644
--- a/INSTALL
+++ b/INSTALL
@@ -75,3 +75,15 @@ Issues of note:
history graphically
- "ssh" is used to push and pull over the net
+
+ - "perl" and POSIX-compliant shells are needed to use most of
+ the barebone Porcelainish scripts.
+
+ - "python" 2.3 or more recent; if you have 2.3, you may need
+ to build with "make WITH_OWN_SUBPROCESS_PY=YesPlease".
+
+ - Some platform specific issues are dealt with Makefile rules,
+ but depending on your specific installation, you may not
+ have all the libraries/tools needed, or you may have
+ necessary libraries at unusual locations. Please look at the
+ top of the Makefile to see what can be adjusted for your needs.
Compilation finished at Fri Nov 11 11:24:14
^ permalink raw reply related
* Re: merge-recursive: include heapq?
From: Andrew Vasquez @ 2005-11-11 19:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git
In-Reply-To: <20051111185246.GB13524@steel.home>
On Fri, 11 Nov 2005, Alex Riesen wrote:
> Johannes Schindelin, Fri, Nov 11, 2005 15:23:04 +0100:
> > I get this when pulling:
> >
> > -- snip --
> > Traceback (most recent call last):
> > File "./git-merge-recursive", line 4, in ?
> > from heapq import heappush, heappop
> > ImportError: No module named heapq
> > -- snap --
> >
> > Okay, my python is *old*:
> >
> > $ python -V
> > Python 2.2.1
> >
> > Is it worthwhile to include heapq as we did with subprocess? Or should I
> > upgrade...
>
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Traceback (most recent call last):
> File "/home/raa/bin/git-merge-recursive", line 8, in ?
> from gitMergeCommon import *
> File "/home/raa/share/git-core/python/gitMergeCommon.py", line 14, in ?
> import subprocess
> ImportError: No module named subprocess
> Automatic merge failed/prevented; fix up by hand
Had the same problem earlier today, building with
WITH_OWN_SUBPROCESS_PY fixed things up...
--
av
^ permalink raw reply
* Re: merge-recursive: include heapq?
From: Alex Riesen @ 2005-11-11 18:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511111520260.7575@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Fri, Nov 11, 2005 15:23:04 +0100:
> I get this when pulling:
>
> -- snip --
> Traceback (most recent call last):
> File "./git-merge-recursive", line 4, in ?
> from heapq import heappush, heappop
> ImportError: No module named heapq
> -- snap --
>
> Okay, my python is *old*:
>
> $ python -V
> Python 2.2.1
>
> Is it worthwhile to include heapq as we did with subprocess? Or should I
> upgrade...
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Traceback (most recent call last):
File "/home/raa/bin/git-merge-recursive", line 8, in ?
from gitMergeCommon import *
File "/home/raa/share/git-core/python/gitMergeCommon.py", line 14, in ?
import subprocess
ImportError: No module named subprocess
Automatic merge failed/prevented; fix up by hand
That said, I thought an upgrade was worth it and upgraded my 2.3 to 2.4 :)
^ permalink raw reply
* Re: git-core-arch: Missing dependency
From: Junio C Hamano @ 2005-11-11 18:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Chris Wright
In-Reply-To: <4374E0EF.2020801@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
>>
>>>The command git-archimport makes use of tla, but the relevant package(s) are
>>>not on the requirements
>> Thanks. Should the fix be like this?
>> Group: Development/Tools
>> -Requires: git-core = %{version}-%{release}
>> +Requires: git-core = %{version}-%{release}, tla
>
> Just to be anal;
> Requires doesn't usually include the %release,...
Obviously both you and Chris (who did the part you are quoting
for us) know RPM spec a lot better than I do, and I see two
experts contradicting with each other. It could have been just
an oversight, or it might have done deliberately --- I cannot
judge myself, so I punt here. I'll remove "-%{release}" when I
hear Chris says he agrees with you.
Thanks both.
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Alex Riesen @ 2005-11-11 18:42 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <437494B2.30309@hogyros.de>
Simon Richter, Fri, Nov 11, 2005 13:55:14 +0100:
> >But you shouldn't care if you have reasonably recent git everywhere:
> >symlinks and their absence already handled:
>
> Well, I don't have working directories on USB sticks, so I don't
> actually use the symlinks, would they be there, but I'm definitely
> annoyed by not being able to copy a .git directory from some project
> over and be done with it.
>
Reasonable, perhaps. But are the git-pull and -clone _that_ slow or
awkward? Besides, you'd probably end up copying more than you'd want.
That's interesting case, btw. I'm restoring git mailing list in cc, so
it gets a bit wider of auditorium.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-11 18:37 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <43730E39.6030601@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> Junio C Hamano wrote:
>> - One important newcomer is git-pack-redundant...
>
> IMHO git-prune-packed should prune redundant pack files...
Maybe not in git-prune-packed, but you are right. We should at
least do that in git-prune. Maybe with something like the patch
at the end?
>> Oh, and we will not be moving things out of /usr/bin/ during 1.0
>> timeframe.
>
> :( bummer. I do like the elegance of having /usr/bin/git executing
> stuff out of /usr/libexec/git.
Bummer here as well. This is not my first preference, but more
or less "all things considered...". I can go over cogito and
stgit with Pasky and Catalin and coordinate the transition, but
at the same time, everybody's existing scripts need to be
adjusted. As Linus said, we broke kernel.org snapshot scripts
number of times.
Also places we execute git-upload-pack and git-receive-pack over
an SSH connection need to be updated to execute 'git' with the
first parameter 'upload-pack' and 'receive-pack' to make sure it
would keep working with older or newer git on the other end.
After all that happens, we can start installing things in
/usr/lib/git/. During the transition, the C rewrite of git
wrapper posted by Andreas Ericsson might help, so I am planning
to merge it before 1.0, after deciding what the right word for
the "path to the rest of git executables" should be.
So let's say 1.0 will ship with all things in /usr/bin/, with
updated docs that explain the situation: (1) the dash form
'git-frotz' is being deprecated, and you are encouraged to spell
it as 'git frotz'; (2) if you want to use the dash form in your
scripts for performance reasons, you need to have something like
PATH="$(git --exec-path):$PATH" at the beginning of your script.
And after some time (say 2 months) we can switch.
I just do not want to wait that long before 1.0.
-- >8 -- cut here -- >8 --
[PATCH] git-prune: prune redundant packs.
---
diff --git a/git-prune.sh b/git-prune.sh
index ef31bd2..aa79807 100755
--- a/git-prune.sh
+++ b/git-prune.sh
@@ -27,3 +27,14 @@ sed -ne '/unreachable /{
}
git-prune-packed $dryrun
+
+redundant=$(git-pack-redundant --all)
+if test "" != "$redundant"
+then
+ if test "" = $dryrun
+ then
+ echo "$redundant" | xargs rm -f
+ else
+ echo rm -f "$redundant"
+ fi
+fi
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 0.99.9g
From: Jim Radford @ 2005-11-11 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7v4q6kxm9c.fsf@assigned-by-dhcp.cox.net>
On Thu, Nov 10, 2005 at 12:48:15PM -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> > Jim Radford wrote:
> >> The main reason I see for splitting cvs and email import out is the
> >> non-standard dependencies, cvsps and perl(Email::Valid).
> > Define "non-standard". String::ShellQuote isn't installed by default on
> > Fedora Core 3 but is required by git-archimport.
You are right. I had missed that it required String::ShellQuote. It
should go in it's own RPM (and it already has).
-Jim
^ permalink raw reply
* Re: git-core-arch: Missing dependency
From: Andreas Ericsson @ 2005-11-11 18:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vy83vnl7r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Horst von Brand <vonbrand@inf.utfsm.cl> writes:
>
>
>>The command git-archimport makes use of tla, but the relevant package(s) are
>>not on the requirements
>
>
> Thanks. Should the fix be like this?
>
> Group: Development/Tools
> -Requires: git-core = %{version}-%{release}
> +Requires: git-core = %{version}-%{release}, tla
Just to be anal;
Requires doesn't usually include the %release, since that's supposed to
represent changes in the spec-file rather than the source (although
patches included in the spec-file often counts as a new %release, but
that's no reason to make it so in the official spec).
I really have to sobner up and get cracking on that spec-file thingie
stuff. Or some such.
Cheers for the beers and review of the peers.
Hooray for firday. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: H. Peter Anvin @ 2005-11-11 17:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, linux-kernel
In-Reply-To: <Pine.LNX.4.63.0511111516170.7575@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> Two reasons against renaming:
>
> - we call it fsck-objects for a reason. We are working on a file system,
> which just so happens to be implemented in user space, not kernel space.
> If lost+found has to find a new name, so does fsck-objects.
>
I'm sorry, but that is bull. The problem here isn't the conventional
naming, it's that you're implementing your filesystem on top of another
filesystem, and you're running into a layering conflict.
> - lost+found has a special meaning, granted. So, a backup would not be
> made of it. So what? I *don't* want it backup'ed. I want to repair what
> was wrong with it. When I repaired it, the result is stored somewhere
> else. To backup lost+found would make as much sense as to backup /tmp.
>
The default should ALWAYS be no data loss.
-hpa
^ permalink raw reply
* Re: HTTP redirection with git-clone/git-fetch ?
From: Junio C Hamano @ 2005-11-11 17:38 UTC (permalink / raw)
To: Josef Weidendorfer, Nick Hengeveld; +Cc: git
In-Reply-To: <200511101409.48618.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> This should fix it, although it still tries every GET with the original
>> URL which is a bit inefficient.
>
> Thanks, I just sent a patch for git-clone, including your patch, to
> Junio.
Thank you both.
^ permalink raw reply
* Re: git-core-arch: Missing dependency
From: Junio C Hamano @ 2005-11-11 17:33 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <200511111446.jABEk6QM023362@pincoya.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> The command git-archimport makes use of tla, but the relevant package(s) are
> not on the requirements
Thanks. Should the fix be like this?
-- >8 --
Subject: RPM: arch submodule needs tla.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-core.spec.in | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 76d3d1c302c20b82fd976e958aabd19f7f01e7b5
a12a9bcce8347f5e5349b05fcd65629e6846a854
diff --git a/git-core.spec.in b/git-core.spec.in
index cf7e942..6a482ad 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -36,7 +36,7 @@ Git tools for importing CVS repositories
%package arch
Summary: Git tools for importing Arch repositories
Group: Development/Tools
-Requires: git-core = %{version}-%{release}
+Requires: git-core = %{version}-%{release}, tla
%description arch
Git tools for importing Arch repositories.
---
0.99.9.GIT
^ permalink raw reply related
* Re: Strange merge conflicts against earlier merge.
From: Petr Baudis @ 2005-11-11 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64qzozyx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Nov 11, 2005 at 06:29:10PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - The above turned out to have a risky corner case, especially
> when one side reverted a patch and the other one did not. To
> address this, read-tree was rewritten and 3-way form of
> read-tree can take more than three trees these days, letting
> you feed it all the merge base candidates. This code is used
> in 'resolve' strategy.
Yes, but what I didn't find out is whether the additional trees result
in additional stages, what are the trivial merging rules, how does it
play together with git-merge-index, etc. Doesn't seem to be documented
either.
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: Strange merge conflicts against earlier merge.
From: Junio C Hamano @ 2005-11-11 17:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111114511.GQ30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Does core GIT have support for multibase merges, except for the
> recursive merge strategy? How do you do it?
There were lengthy discussion on this and a lot of work that
went into the resolution. We do three things.
- The first implementation does a trial read-tree 3-way using
each of the base candidates without smudging the working
tree, and counts paths that need file-level merges, to guess
the best base, and uses that base. This is in the 'stupid'
stratagy.
- The above turned out to have a risky corner case, especially
when one side reverted a patch and the other one did not. To
address this, read-tree was rewritten and 3-way form of
read-tree can take more than three trees these days, letting
you feed it all the merge base candidates. This code is used
in 'resolve' strategy.
- The 'recursive' strategy tries to come up with a merge of the
candidate bases and uses it as the base of the final merge.
^ 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