* Re: Which packages/versions are needed to build documentation
From: Simon Richter @ 2005-11-09 17:24 UTC (permalink / raw)
To: Alan Chandler, git
In-Reply-To: <200511091655.51093.alan@chandlerfamily.org.uk>
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
Hi,
> On my debian sarge system it fails almost immediately
Just take the asciidoc package from unstable, last time I looked it had
no dependencies that were unfulfillable from sarge.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Which packages/versions are needed to build documentation
From: Alan Chandler @ 2005-11-09 16:55 UTC (permalink / raw)
To: git
I have just downloaded git-core-0.99f
On my debian unstable system I can build the documentation just fine
On my debian sarge system it fails almost immediately
alan@roo:Documentation$ make
asciidoc -b xhtml11 -d manpage -f asciidoc.conf git-add.txt
WARNING: non-standard xhtml11 backend
FAILED: incomplete configuration files
make: *** [git-add.html] Error 1
alan@roo:Documentation$
I've patched up asciidoc as per instructions.
Searching for a package (dpkg -S xhtmll) that uses anything to do with xhtml11
shows nothing on Sarge, and shows asciidoc (and some other things, like
quanta and mozilla) on debian unstable. I assume therefore its just a
version issue of asciidoc, although I am confused because the note about
patching asciidoc assumes you had 6.0.3 installed - which is what debian
sarge has.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Comments on recursive merge..
From: Linus Torvalds @ 2005-11-09 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q6mgm1l.fsf@assigned-by-dhcp.cox.net>
On Wed, 9 Nov 2005, Junio C Hamano wrote:
>
> As you pointed out, still_interesting means "after we are done
> with this commit, do we still have something interesting to be
> processed?", and the later "extra < 0" check compensates for
> this. After I pop the last interesting commit, I still look at
> its parents and push them back into the list.
That "extra" check only helps once. If we ever hit the "extra--", it's
gone.
In other words, follow this:
- we start out with "extra = 0" (default value)
- we've got one "interesting" commit left, and we just popped it.
- we now have "still_interesting = 0"
- the commit has just one parent, and it's not something we've seen
before, so we add it to the seen list and decrement "extra", which is
now -1. We then insert it back to the list.
- we go back up, pop the thing we just got, and now there are again no
interesting commits on the list any more, so "still_interesting = 0".
- now "extra" is -1, and we break out of the loop without ever
percolating the flags of this commit to its parents.
No?
> It seems to be doing the right thing after all. I hate to admit it, but
> I have been having hard time figuring out how this thing works X-<. In
> the meantime, I've checked commits from linux-2.6 history that have more
> than one merge-base candidates.
I'm not very impressed by "it works for the seven cases I tried".
It's entirely possible that there _is_ some reason it always works, but if
so, I'd like to understand it. More likely, it works in _practice_ because
the only way to trigger anything else is likely such a perverse commit
history that you'd never see it, but hey..
Also, I don't think this has necessarily anything to do with "multiple
merge bases". As far as I can tell, we can find a potential "merge base"
that starts the culling of uniniteresting things, but some other branch
(that we haven't followed yet - perhaps the one we just broke out of
early) may end up causing an _earlier_ commit to turn out to also be a
merge-base, and the merge-base we found originally turns out to be a
parent of the new one, and thus totally uninteresting.
See what I'm saying? Even with just _one_ well-defined merge base, we
might hit it.
It so happens that because we traverse the commit history in date order,
we almost never (but the keyword here is _almost_) hit the case where a
child of a commit ends up being parsed _after_ the commit that is its
parent. That only happens when there are non-synchronized clocks etc, and
there are very few cases of that in the kernel tree.
Just to see how rare that is, do this:
git-rev-list --pretty=raw HEAD |
grep '^committer' |
cut -d'>' -f2 |
cut -d' ' -f2 > date-list
which basically generates the list of dates of commits in the kernel tree,
sorted in the natural order that we always traverse the commits in.
Now, do
sort -nr date-list | diff -u date-list -
to see how often the dates are off. I'm seeing only _three_ commits that
have time-warps (ie they were "earlier" than one of their parents). Out of
13,000+.
So walking things in date order _almost_ always does the right thing just
by mistake (well, it's not "mistake", of course. It's by design: it's the
closest we can get to a nice balanced walk. But the point is that it's
still just a heuristic, not something we can absolutely depend on).
And THAT was the reason for the problem with the original git-merge-base
algorithm. Not multiple merge-bases (which was admittedly another
problem), but the fact that it didn't give the right merge-base at all due
to time warps.
(Again - it may be that there's something in show-branch that makes the
optimization valid, but I just don't understand it).
Linus
^ permalink raw reply
* Re: Comments on recursive merge..
From: Petr Baudis @ 2005-11-09 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v4q6mgm1l.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Nov 09, 2005 at 11:20:22AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I do not think "git-show-branch --merge-base" can be any more
> efficient than "git-merge-base --all". It does _more_ things
> (probably unnecessary things as well). Pasky's number could be
> just an artifact of hot/cold cache difference.
Certainly not that. But I've fetched in the meantime and now show-branch
takes much longer - median 0.078s (git-merge-base's median still stays
around 0.128s). So possibly git-show-branch did some smart optimization
right away in the previous case. I can try to track down the particular
commits if there's any interest.
--
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: Expected Behavior?
From: Jon Loeliger @ 2005-11-09 13:38 UTC (permalink / raw)
To: git
> Could you check diff between /usr/bin/git-merge-recursive and
> git-merge-recursive.py in your source tree and see if the
> appending to sys.path points at the right place (i.e. where the
> make installs gitMergeCommon.py)?
jdl.com 211 % diff /usr/src/git-core/git-merge-recursive /usr/bin/git-merge-recursive
jdl.com 212 %
jdl.com 213 % ll /usr/src/git-core/git-merge-recursive /usr/bin/git-merge-recursive
32 -rwxr-xr-x 1 root root 29181 Nov 8 20:17 /usr/bin/git-merge-recursive
32 -rwxr-xr-x 1 jdl src 29181 Nov 8 08:36 /usr/src/git-core/git-merge-recursive
This would be a problem, though:
jdl.com 216 % head -15 /usr/bin/git-merge-recursive
#!/usr/bin/python
import sys, math, random, os, re, signal, tempfile, stat, errno, traceback
from heapq import heappush, heappop
from sets import Set
sys.path.append('''/home/jdl/share/git-core/python''')
from gitMergeCommon import *
originalIndexFile = os.environ.get('GIT_INDEX_FILE',
os.environ.get('GIT_DIR', '.git') + '/index')temporaryIndexFile = os.environ.get('GIT_DIR', '.git') + \
'/merge-recursive-tmp-index'
def setupIndex(temporary):
try:
Looks like /home/jdl/share got left instead of /usr/share.
So. The root of the problem is that I followed the INSTALL
instructions:
Git installation
Normally you can just do "make" followed by "make install", and that
will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
make prefix=/usr install
I ran "make" as myself, and then later
I ran "make prefix=/usr install" as root.
However, the path substitution happened as part of the
"all" target and not as part of the "install" target:
SCRIPT_PYTHON = \
git-merge-recursive.py
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
gitk git-cherry-pick
all: $(PROGRAMS) $(SCRIPTS)
$(patsubst %.py,%,$(SCRIPT_PYTHON)) : % : %.py
rm -f $@
sed -e '1s|#!.*python|#!$(call shq,$(PYTHON_PATH))|' \
-e 's|@@GIT_PYTHON_PATH@@|$(call shq,$(GIT_PYTHON_DIR))|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
$@.py >$@
chmod +x $@
So, It looks like either:
1) Change the INSTALL documentation and process
to require "make prefix=/...." also during the build,
or
2) Change the Makefile to do install-related path
substitutions at "make install" time.
My preference would be the latter (ie, take $(SCRIPTS) off
the "all: " line), but you may have better notions here.
Like, do people run stuff out of the build directory between
a "make" and a "make install"? Dunno.
jdl
^ permalink raw reply
* Re: git binary directory?
From: Andreas Ericsson @ 2005-11-09 13:32 UTC (permalink / raw)
To: git
In-Reply-To: <20051107004346.GR1431@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
Petr Baudis wrote:
>
> I want to avoid extra fork()s and exec()s. They seem to routinely matter
> in orders of magnitude of speed in tight loops.
>
Give this a whirl. It's still slower than using the git-<something>
form, but it's quite an improvement anyways.
#############
$ time for i in `seq 1 10000`; do git send-pack --help >/dev/null 2>&1; done
real 0m28.921s
user 0m12.626s
sys 0m14.219s
$ time for i in `seq 1 10000`; do ./git send-pack --help >/dev/null
2>&1; done
real 0m12.129s
user 0m4.444s
sys 0m7.615s
$ time for i in `seq 1 10000`; do git-send-pack --help >/dev/null 2>&1; done
real 0m9.069s
user 0m3.481s
sys 0m5.558s
##############
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
[-- Attachment #2: git.c --]
[-- Type: text/x-csrc, Size: 3703 bytes --]
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <limits.h>
#include <stdarg.h>
#include <glob.h>
#ifndef PATH_MAX
# define PATH_MAX 4096
#endif
static const char git_usage[] =
"Usage: git [ --version ] [ --lib=<GIT_LIB> ] COMMAND [ OPTIONS ] [ TARGET ]";
struct string_list {
size_t len;
char *str;
struct string_list *next;
};
/* most gui terms set COLUMNS (although some don't export it) */
static int columns(void)
{
char *col_string = getenv("COLUMNS");
int n_cols = 0;
if (col_string && (n_cols = atoi(col_string)) > 0)
return n_cols;
return 80;
}
static inline void mput_char(char c, unsigned int num)
{
unsigned int i;
for(i = 0; i < num; i++)
putchar(c);
}
static void fmt_print_string_list(struct string_list *list, int longest)
{
int cols;
int space = longest + 1; /* space between start of string1 and string2 */
int max_cols = columns() - 1;
cols = max_cols / space;
if(cols < 1) {
cols = 1;
space = 0;
}
while (list) {
int c = cols;
printf(" ");
for(c = cols; c; c--) {
if (!list)
break;
printf("%s", list->str);
if (space && c != 1)
mput_char(' ', space - list->len);
list = list->next;
}
putchar('\n');
}
}
static void usage(char *path, const char *fmt, ...)
__attribute__((__format__(__printf__, 2, 3)));
static void usage(char *path, const char *fmt, ...)
{
struct string_list *list, *tail;
unsigned int longest = 0, i;
glob_t gl;
list = tail = NULL;
if (!fmt)
puts(git_usage);
else {
printf("git: ");
va_list ap;
va_start(ap, fmt);
vprintf(fmt, ap);
va_end(ap);
}
putchar('\n');
if (!path)
exit(1);
if (chdir(path) < 0) {
printf("git: '%s': %s\n", path, strerror(errno));
exit(1);
}
printf("\ngit commands available in '%s'\n", path);
printf("----------------------------");
mput_char('-', strlen(path));
putchar('\n');
glob("git-*", 0, NULL, &gl);
for (i = 0; i < gl.gl_pathc; i++) {
int len = strlen(gl.gl_pathv[i] + 4);
if(access(gl.gl_pathv[i], X_OK))
continue;
if (longest < len)
longest = len;
if (!tail)
tail = list = malloc(sizeof(struct string_list));
else {
tail->next = malloc(sizeof(struct string_list));
tail = tail->next;
}
tail->len = len;
tail->str = gl.gl_pathv[i] + 4;
tail->next = NULL;
}
fmt_print_string_list(list, longest);
puts("\nman-pages can be reached through 'man git-<COMMAND>'\n");
exit(1);
}
#define DEFAULT_GIT_LIB "/usr/bin"
#define GIT_VERSION "0.99.9.GIT"
int main(int argc, char **argv, char **envp)
{
char git_command[PATH_MAX + 1];
char *git_lib = getenv("GIT_LIB");
char wd[PATH_MAX + 1], libdir[PATH_MAX + 1];
getcwd(wd, PATH_MAX);
if(argc == 1) {
if (git_lib)
usage(git_lib, NULL);
usage(DEFAULT_GIT_LIB, NULL);
}
argv++;
/* always *argv since we inc it if we hit an option */
while (argc-- && !strncmp(*argv, "--", 2)) {
char *arg = (*argv++) + 2;
if (!strncmp(arg, "lib=", 3))
git_lib = arg + 4;
else if (!strncmp(arg, "version", 7)) {
printf("git version %s\n", GIT_VERSION);
exit(0);
}
else
usage (NULL, NULL);
}
if (!git_lib)
git_lib = DEFAULT_GIT_LIB;
/* allow relative paths, but run with exact */
if (chdir(git_lib)) {
printf("git: '%s': %s\n", git_lib, strerror(errno));
exit (1);
}
getcwd(libdir, sizeof(libdir));
chdir(wd);
snprintf(git_command, sizeof(git_command), "%s/git-%s", libdir, *argv);
if (access(git_command, X_OK))
usage(git_lib, "'%s' is not a git-command", *argv);
if (execve(git_command, argv, envp)) {
printf("Failed to run command '%s': %s\n", git_command, strerror(errno));
return 1;
}
/* not reached */
return 0;
}
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-09 10:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v8xvyd2bh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> It does:
>>
>> struct commit *commit = pop_one_commit(list_p);
>> int still_interesting = !!interesting(*list_p);
>>
>> in that order: it looks whether there are any interesting commits left
>> _after_ it has popped the top-of-stack.
>
> The problem is most of the time hidden,...
As you pointed out, still_interesting means "after we are done
with this commit, do we still have something interesting to be
processed?", and the later "extra < 0" check compensates for
this. After I pop the last interesting commit, I still look at
its parents and push them back into the list.
It seems to be doing the right thing after all. I hate to admit
it, but I have been having hard time figuring out how this thing
works X-<. In the meantime, I've checked commits from linux-2.6
history that have more than one merge-base candidates.
"git-merge-base --all" and "git-show-branch --merge-base" give
the same answer to all of them [*1*].
I do not think "git-show-branch --merge-base" can be any more
efficient than "git-merge-base --all". It does _more_ things
(probably unnecessary things as well). Pasky's number could be
just an artifact of hot/cold cache difference.
[Footnote]
*1* Here are the commits I used from linux-2.6 repository that
have more than one commits:
ba9b543d5bec0a7605952e2ba501fb8b0f3b6407
84ffa747520edd4556b136bdfc9df9eb1673ce12
da28c12089dfcfb8695b6b555cdb8e03dda2b690
3190186362466658f01b2e354e639378ce07e1a9
0c168775709faa74c1b87f1e61046e0c51ade7f3
0e396ee43e445cb7c215a98da4e76d0ce354d9d7
467ca22d3371f132ee225a5591a1ed0cd518cb3d
^ permalink raw reply
* Re: [PATCH 0/4] Add git-pack-intersect
From: Andreas Ericsson @ 2005-11-09 11:58 UTC (permalink / raw)
To: git
In-Reply-To: <20051109111917.GB30496@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Nov 09, 2005 at 02:20:59AM CET, I got a letter
> where Lukas Sandström <lukass@etek.chalmers.se> said that...
>
>>This patch series adds git-pack-intersect. It finds redundant packs
>>by calculating the union of all objects present in .git/objects/pack
>>and then computing the smallest set of packs which contain all the
>>objects in this union.
>
>
> Sounds nice, except the name - it does something else than what the name
> says, so perhaps something like 'git-pack-redundant' would be more
> appropriate.
>
It would be better if it was in git-prune or a default action for
git-repack. I can't imagine a scenario where keeping redundant packfiles
is useful.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-09 11:24 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, Jon Loeliger, git
In-Reply-To: <20051108210332.GB23265@c165.ib.student.liu.se>
Dear diary, on Tue, Nov 08, 2005 at 10:03:32PM CET, I got a letter
where Fredrik Kuivinen <freku045@student.liu.se> said that...
> On Mon, Nov 07, 2005 at 10:00:11PM -0800, Junio C Hamano wrote:
> > Jon Loeliger <jdl@freescale.com> writes:
> >
> > > That is, after the merge, file3 appears to have simply kept
> > > the contents of the current, master branch. Why wasn't the
> > > dev branch represented here?
> > >
> > > I _almost_ think I get it, and then *poof*...
> >
> > Automerge completely punted for this path, and at this point, it
> > is still unmerged:
> >
> > ------------
> > $ git ls-files --unmerged
> > 100644 c4da0eb.... 2 file3
> > 100644 fbc2aa4.... 3 file3
> > ------------
> >
> > Three-way "git-read-tree -m -u O A B" (O is for old, A is ours
> > and B is hers) puts O in stage1, A in stage2 and B in stage3.
> > This path did not exist in O so we only have them in stage2 and
> > stage3. You could compare the stages like this:
> >
>
> Jon: You could try to this merge with the recursive merge strategy
> (git merge -s recursive 'merge message' master dev) If you do, you
> _should_ get something like:
>
> CONFLICT (add/add): File file3 added non-identically in both
> branches. Adding as file3_master and file3_dev instead.
>
> You will then end up with file3_master and file3_dev in your working
> tree, which corresponds to file3 in the master branch and file3 in the
> dev branch, respectively.
The world would be so much better if there would be just a _single_
per-file automerger instead of three right now...
I'm planning to feed back the automerger stuff from Cogito to GIT like I
already did once, but it's not a priority right now so it may take some
time (unless someone else does it, which is something I certainly
wouldn't oppose).
But in the longer term even the recursive merge should use the same one,
so either we should enhance the shell one to handle all the cases, or
split out the python per-file automerger from recursive merge and make
it possible to use this one separately. This is probably more viable
option in the longer term, even though I personally don't grok python
very well - whatever, at least I'll have to get better. ;-)
--
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: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Petr Baudis @ 2005-11-09 11:20 UTC (permalink / raw)
To: Ben Clifford; +Cc: Nick Hengeveld, Git Mailing List, Martin Langhoff
In-Reply-To: <5C8707EC-3A6F-46B6-8FB1-AAB0842DDDD1@hawaga.org.uk>
Dear diary, on Wed, Nov 09, 2005 at 10:49:30AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
>
> On 9 Nov 2005, at 12:09, Nick Hengeveld wrote:
> >
> >Those curl result codes all look wrong, and sounds like a memory issue
> >that Johannes Schindelin recently fixed in commit
> >90279074ca5cc336a8bfffd47d19d089b291b432. Does your git build have
> >that
> >patch?
>
> I did not - I've pulled and rebuilt from master, and have that commit
> now.
> It works better (not perfectly (there's a tags 403) but I suspect
> that may be permissions config at my server end or absence of tags in
> my repo or something mumble). I can do this a bunch of times in a row
> with the same results and the resulting cloned repository looks sane.
This likely means that you don't permit directory listing of the tags/
subdir. Since Cogito is just about to cease using it, though, it's up to
you whether you'll go through the trouble of enabling it or waiting for
new Cogito version. ;-)
--
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 0/4] Add git-pack-intersect
From: Petr Baudis @ 2005-11-09 11:19 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, junkio
In-Reply-To: <43714EFB.5070705@etek.chalmers.se>
Dear diary, on Wed, Nov 09, 2005 at 02:20:59AM CET, I got a letter
where Lukas Sandström <lukass@etek.chalmers.se> said that...
> This patch series adds git-pack-intersect. It finds redundant packs
> by calculating the union of all objects present in .git/objects/pack
> and then computing the smallest set of packs which contain all the
> objects in this union.
Sounds nice, except the name - it does something else than what the name
says, so perhaps something like 'git-pack-redundant' would be more
appropriate.
--
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
* [PATCH] merge-recursive: Fix support for branch names containing slashes
From: Fredrik Kuivinen @ 2005-11-09 10:42 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Junio C Hamano, git
In-Reply-To: <20051109081906.GA4960@c165.ib.student.liu.se>
On Wed, Nov 09, 2005 at 09:19:06AM +0100, Fredrik Kuivinen wrote:
> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:
> > Fredrik Kuivinen <freku045@student.liu.se> writes:
> >
> > >> Oops, I missed that part. This is unsafe in theory, if you
> > >> could overwrite existing file3_master or file3_dev. Does that
> > >> matter in practice?
> > >
> > > It wont overwrite any existing files. If there is a file named
> > > 'file3_master' then the new file will be named 'file3_master_1' and if
> > > that file also exists the new file will be named 'file3_master_2', and
> > > so on.
> >
> > Another thing to watch out is that a branch name could have a
> > slash in it. It might make more sense to just name the heads file3~2
> > or file3~3 (with as many ~s repeated to avoid name clashes) like
> > Pasky does.
> >
>
> Oups, I haven't thought about that. I kind of like the idea that you
> can see the branch name in the file names though. How about replacing
> any slashes in the branch names with underscores? So the branch
> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and
> '_foo_bar_<number>'.
>
And here is a patch to implement this. Should apply cleanly on top of
'[PATCH] merge-recursive: Fix limited output of rename messages'.
---
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-recursive.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 1dd8c1800d7dd0425bc93f4c9441acfb207b1488
795e2900e8804af53263821c177a270cd2d7c2c0
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index 3657875..90e889c 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -295,6 +295,7 @@ def uniquePath(path, branch):
else:
raise
+ branch = branch.replace('/', '_')
newPath = path + '_' + branch
suffix = 0
while newPath in currentFileSet or \
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] merge-recursive: Only print relevant rename messages
From: Fredrik Kuivinen @ 2005-11-09 10:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, Linus Torvalds, Git Mailing List
In-Reply-To: <7v64r4qai6.fsf@assigned-by-dhcp.cox.net>
On Mon, Nov 07, 2005 at 03:54:57PM -0800, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > @@ -178,7 +181,7 @@ def mergeFile(oPath, oSha, oMode, aPath,
> > sha = bSha
> > else:
> > if aSha != oSha and bSha != oSha:
> > - merge = True
> > + merge = MERGE_TRIVIAL
>
> The rest looks good to me, but are you sure about this part? I
> have a feeling that the above "and" should be "or", meaning, we
> check to see if there is _any_ change, and default to TRIVIAL,
> but later we would find that we need a real merge and then
> promote it to MERGE_3WAY.
>
You are right. The code actually do the right thing, but it does it by
accident. Please apply the following patch.
---
merge-recursive: Fix limited output of rename messages
The previous code did the right thing, but it did it by accident.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-recursive.py | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
applies-to: bb7dd65e1d945edbe0137a761ebc388c7394067a
f56613498cd7fb7013f532a04e63b580314ed957
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index 9983cd9..3657875 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -162,13 +162,10 @@ def mergeTrees(head, merge, common, bran
# Low level file merging, update and removal
# ------------------------------------------
-MERGE_NONE = 0
-MERGE_TRIVIAL = 1
-MERGE_3WAY = 2
def mergeFile(oPath, oSha, oMode, aPath, aSha, aMode, bPath, bSha, bMode,
branch1Name, branch2Name):
- merge = MERGE_NONE
+ merge = False
clean = True
if stat.S_IFMT(aMode) != stat.S_IFMT(bMode):
@@ -181,7 +178,7 @@ def mergeFile(oPath, oSha, oMode, aPath,
sha = bSha
else:
if aSha != oSha and bSha != oSha:
- merge = MERGE_TRIVIAL
+ merge = True
if aMode == oMode:
mode = bMode
@@ -211,7 +208,6 @@ def mergeFile(oPath, oSha, oMode, aPath,
os.unlink(src1)
os.unlink(src2)
- merge = MERGE_3WAY
clean = (code == 0)
else:
assert(stat.S_ISLNK(aMode) and stat.S_ISLNK(bMode))
@@ -590,7 +586,7 @@ def processRenames(renamesA, renamesB, b
if merge or not clean:
print 'Renaming', fmtRename(path, ren1.dstName)
- if merge == MERGE_3WAY:
+ if merge:
print 'Auto-merging', ren1.dstName
if not clean:
@@ -668,7 +664,7 @@ def processRenames(renamesA, renamesB, b
if merge or not clean:
print 'Renaming', fmtRename(ren1.srcName, ren1.dstName)
- if merge == MERGE_3WAY:
+ if merge:
print 'Auto-merging', ren1.dstName
if not clean:
---
0.99.9.GIT
^ permalink raw reply related
* Re: Errors cloning over http -- git-clone and cg-clone fail to fetch a reachable object...
From: Ben Clifford @ 2005-11-09 9:49 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Git Mailing List, Martin Langhoff
In-Reply-To: <20051109010922.GC5830@reactrix.com>
On 9 Nov 2005, at 12:09, Nick Hengeveld wrote:
>
> Those curl result codes all look wrong, and sounds like a memory issue
> that Johannes Schindelin recently fixed in commit
> 90279074ca5cc336a8bfffd47d19d089b291b432. Does your git build have
> that
> patch?
I did not - I've pulled and rebuilt from master, and have that commit
now.
It works better (not perfectly (there's a tags 403) but I suspect
that may be permissions config at my server end or absence of tags in
my repo or something mumble). I can do this a bunch of times in a row
with the same results and the resulting cloned repository looks sane.
Ben
!535 [0] benc@piva:~/tmp/xa4$ cg clone http://www.hawaga.org.uk/
gitcompletion.git
defaulting to local storage area
20:46:16 URL:http://www.hawaga.org.uk/gitcompletion.git/HEAD [41/41] -
> "refs/heads/.origin-fetching" [1]
progress: 28 objects, 7901 bytes
http://www.hawaga.org.uk/gitcompletion.git/refs/tags/:
20:46:36 ERROR 403: Forbidden.
FINISHED --20:46:36--
Downloaded: 0 bytes in 0 files
New branch: a108bdc110dad770ec5c092759a8bc511790d21f
Cloned to gitcompletion/ (origin http://www.hawaga.org.uk/
gitcompletion.git available as branch "origin")
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
^ permalink raw reply
* Re: Expected Behavior?
From: Fredrik Kuivinen @ 2005-11-09 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vmzkenzcx.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> >> Oops, I missed that part. This is unsafe in theory, if you
> >> could overwrite existing file3_master or file3_dev. Does that
> >> matter in practice?
> >
> > It wont overwrite any existing files. If there is a file named
> > 'file3_master' then the new file will be named 'file3_master_1' and if
> > that file also exists the new file will be named 'file3_master_2', and
> > so on.
>
> Another thing to watch out is that a branch name could have a
> slash in it. It might make more sense to just name the heads file3~2
> or file3~3 (with as many ~s repeated to avoid name clashes) like
> Pasky does.
>
Oups, I haven't thought about that. I kind of like the idea that you
can see the branch name in the file names though. How about replacing
any slashes in the branch names with underscores? So the branch
'foo/bar' will give rise to files with suffixes like '_foo_bar' and
'_foo_bar_<number>'.
- Fredrik
^ permalink raw reply
* Re: make tests ignorable with "make -i"
From: Alex Riesen @ 2005-11-09 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20051108211618.GA3224@steel.home>
On 11/8/05, Alex Riesen <raa.lkml@gmail.com> wrote:
> Junio C Hamano, Tue, Nov 08, 2005 20:29:59 +0100:
> > > ... (Or to ignore plainly uninteresting situations because of the
> > > testing being done on say... cygwin ;)
> >
> > Could you tell us which ones break on Cygwin?
> >
So far:
t4000-diff-format.sh
* FAIL 3: validate git-diff-files -p output.
compare_diff_patch current expected
t4006-diff-mode.sh
* FAIL 3: verify
diff -u expected check
t4102-apply-rename.sh
* FAIL 3: validate
test -f bar && ls -l bar | grep "^-..x......"
^ permalink raw reply
* [PATCH] fix cvsexportcommit syntax error
From: Alexander Litvinov @ 2005-11-09 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy83zhyu4.fsf@assigned-by-dhcp.cox.net>
There is a syntax error in cvsexport script:
--- git-cvsexportcommit.perl.orig 2005-11-09 13:00:51.000000000 +0600
+++ git-cvsexportcommit.perl 2005-11-09 13:00:57.000000000 +0600
@@ -64,7 +64,7 @@
last;
}; # found it
die "Did not find $parent in the parents for this commit!";
-s }
+ }
} else { # we don't have a parent from the cmdline...
if (@parents == 1) { # it's safe to get it from the commit
$parent = $parents[0];
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-09 6:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EZgAs-0008B4-QZ@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> Hmmm. That didn't go too well. Concisely:
>
> % git merge -s recursive "Grab dev stuff" master dev
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Traceback (most recent call last):
> File "/usr/bin/git-merge-recursive", line 8, in ?
> from gitMergeCommon import *
> ImportError: No module named gitMergeCommon
> Automatic merge failed/prevented; fix up by hand
Could you check diff between /usr/bin/git-merge-recursive and
git-merge-recursive.py in your source tree and see if the
appending to sys.path points at the right place (i.e. where the
make installs gitMergeCommon.py)? Mine looks like this:
--- git-merge-recursive.py 2005-11-08 02:27:08.000000000 +0000
+++ /usr/bin/git-merge-recursive 2005-11-09 06:17:58.000000000 +0000
@@ -1,10 +1,10 @@
-#!/usr/bin/python
+#!/usr/bin/python2.4
import sys, math, random, os, re, signal, tempfile, stat, errno, traceback
from heapq import heappush, heappop
from sets import Set
-sys.path.append('''@@GIT_PYTHON_PATH@@''')
+sys.path.append('''/usr/share/git-core/python''')
from gitMergeCommon import *
originalIndexFile = os.environ.get('GIT_INDEX_FILE',
By default we set prefix to $HOME so ~/bin/git-merge-recursive
would import ~/share/git-core/python/gitMergeCommon.py. Binary
packaging typically set prefix to /usr, so the executable is in
/usr/bin, and should import from /usr/share/git-core/python/,
which is as your make log shows:
> [ tail end of the make install output ]
>
> install -d -m755 '/usr/share/git-core/templates/'
> (cd blt && tar cf - .) | \
> (cd '/usr/share/git-core/templates/' && tar xf -)
> make[1]: Leaving directory `/usr/src/git-core/templates'
> install -d -m755 '/usr/share/git-core/python'
> install gitMergeCommon.py '/usr/share/git-core/python'
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-09 6:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511081614140.3247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> In general, you need to keep track of one bit per ref, and since we have
> a 32-bit "flags" word and need a couple of bits for other maintenance
> info, pretty much anything that figures out common heads will be limited
> some way.
>
> This is only a limit for the "and" logic - the "or" logic (if we implement
> it) will just share the same status bit for all the refs that are "ored
> together" and thus has no limits.
>
> Oh, and the "and" logic can be extended by running the program multiple
> times, so it's not a "hard" limit, it's just an issue of convenience.
>
> That said, anybody who ever does an octopus of more than just a few heads
> deserves to be shot, so I don't think the limit should matter. The
> recursive strategy should only add the "or" kind of refs, and it
> shouldn't be a problem (apart from just how to describe them).
Come to think of it, git-merge-octopus does AND. If I am
merging topic branches 1, 2, 3,... N into my master, internally
it does an equivalent of merging 1 into master, then 2 into the
result, then C into that result,..., and it uses merge-base of
all the heads merged so far and the original master to pivot on.
And I think this is *wrong*. The merge base of each step when
merging head N does not have to be older than merge base of the
original master and head N, but currently that is not what it
does. I should be ORing them ideally, but even if I do not, I
should be able to just use the merge base of head N and original
master.
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-09 5:50 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20051108225320.GB4805@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
>> Oops, I missed that part. This is unsafe in theory, if you
>> could overwrite existing file3_master or file3_dev. Does that
>> matter in practice?
>
> It wont overwrite any existing files. If there is a file named
> 'file3_master' then the new file will be named 'file3_master_1' and if
> that file also exists the new file will be named 'file3_master_2', and
> so on.
Another thing to watch out is that a branch name could have a
slash in it. It might make more sense to just name the heads file3~2
or file3~3 (with as many ~s repeated to avoid name clashes) like
Pasky does.
^ permalink raw reply
* Re: Expected Behavior?
From: Jon Loeliger @ 2005-11-09 2:58 UTC (permalink / raw)
To: git
<Young Frankenstein> Froe-derick wrote: </Young Frankenstein>
> Jon: You could try to this merge with the recursive merge strategy
> (git merge -s recursive 'merge message' master dev) If you do, you
> _should_ get something like:
>
> CONFLICT (add/add): File file3 added non-identically in both
> branches. Adding as file3_master and file3_dev instead.
Hmmm. That didn't go too well. Concisely:
% git merge -s recursive "Grab dev stuff" master dev
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Traceback (most recent call last):
File "/usr/bin/git-merge-recursive", line 8, in ?
from gitMergeCommon import *
ImportError: No module named gitMergeCommon
Automatic merge failed/prevented; fix up by hand
Full details below.
> You will then end up with file3_master and file3_dev in your working
> tree, which corresponds to file3 in the master branch and file3 in the
> dev branch, respectively.
That'd be cool, because the first thing I tend to want to do
after a failed file merge is look at clear versions of both files.
Gives me a global sense of where the file needs to go... You know.
jdl
[ tail end of the make install output ]
install -d -m755 '/usr/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/usr/share/git-core/templates/' && tar xf -)
make[1]: Leaving directory `/usr/src/git-core/templates'
install -d -m755 '/usr/share/git-core/python'
install gitMergeCommon.py '/usr/share/git-core/python'
% git merge -s recursive "Grab dev stuff" master dev
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Traceback (most recent call last):
File "/usr/bin/git-merge-recursive", line 8, in ?
from gitMergeCommon import *
ImportError: No module named gitMergeCommon
Automatic merge failed/prevented; fix up by hand
% git -v
git version 0.99.9.GIT
% cat /usr/src/git-core/.git/HEAD
f8d294f0a44c4305a9f3a1c70beb6a1c7583f287
% ll /usr/share/git-core/python/
total 16
4 drwxr-xr-x 2 root root 4096 Nov 8 20:17 .
4 drwxr-xr-x 4 root root 4096 Sep 14 19:47 ..
8 -rwxr-xr-x 1 root root 6879 Nov 8 20:17 gitMergeCommon.py
% python
Python 2.3.5 (#2, May 4 2005, 08:51:39)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
^ permalink raw reply
* Re: Comments on recursive merge..
From: Junio C Hamano @ 2005-11-09 1:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511081716450.3247@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> It does:
>
> struct commit *commit = pop_one_commit(list_p);
> int still_interesting = !!interesting(*list_p);
>
> in that order: it looks whether there are any interesting commits left
> _after_ it has popped the top-of-stack.
Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh. You are right.
The problem is most of the time hidden, because we usually do
one extra round (extra usually starts from 0 and we break out
after we say "not interesting anymore" and extra < 0).
Obviously, I was not thinking clearly.
^ permalink raw reply
* [PATCH 4/4] Make git-repack use git-pack-intersect
From: Lukas Sandström @ 2005-11-09 1:25 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, junkio
In-Reply-To: <43714EFB.5070705@etek.chalmers.se>
Make git-repack use git-pack-intersect.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
git-repack.sh | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
applies-to: 73e05dab832dd7320a5128fbf97e693f23ffb949
2cbd6ade19a768eca47f6f7313f6831226ee58b7
diff --git a/git-repack.sh b/git-repack.sh
index d341966..3f28300 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -32,10 +32,6 @@ case ",$all_into_one," in
rev_list=
rev_parse='--all'
pack_objects=
- # This part is a stop-gap until we have proper pack redundancy
- # checker.
- existing=`cd "$PACKDIR" && \
- find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
;;
esac
if [ "$local" ]; then
@@ -46,6 +42,14 @@ name=$(git-rev-list --objects $rev_list
exit 1
if [ -z "$name" ]; then
echo Nothing new to pack.
+ if test "$remove_redandant" = t ; then
+ echo "Removing redundant packs."
+ sync
+ redundant=$(git-pack-intersect -a)
+ if test "$redundant" != "" ; then
+ echo $redundant | xargs rm
+ fi
+ fi
exit 0
fi
echo "Pack pack-$name created."
@@ -58,20 +62,10 @@ exit
if test "$remove_redandant" = t
then
- # We know $existing are all redandant only when
- # all-into-one is used.
- if test "$all_into_one" != '' && test "$existing" != ''
- then
- sync
- ( cd "$PACKDIR" &&
- for e in $existing
- do
- case "$e" in
- ./pack-$name.pack | ./pack-$name.idx) ;;
- *) rm -f $e ;;
- esac
- done
- )
+ sync
+ redundant=$(git-pack-intersect -a)
+ if test "$redundant" != "" ; then
+ echo $redundant | xargs rm
fi
fi
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/4] Add git-pack-intersect to .gitignore
From: Lukas Sandström @ 2005-11-09 1:24 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, junkio
In-Reply-To: <43714EFB.5070705@etek.chalmers.se>
Add git-pack-intersect to .gitignore
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: f4f7accfd9ee93f528c85bae514334fbc7a70be7
7b8da40e79aa09b43ba4590c6bf8169ed85e4871
diff --git a/.gitignore b/.gitignore
index 716c340..6ff2530 100644
--- a/.gitignore
+++ b/.gitignore
@@ -60,6 +60,7 @@ git-mktag
git-name-rev
git-mv
git-octopus
+git-pack-intersect
git-pack-objects
git-parse-remote
git-patch-id
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/4] Add documentation for git-pack-intersect
From: Lukas Sandström @ 2005-11-09 1:23 UTC (permalink / raw)
To: git; +Cc: Lukas Sandström, junkio
In-Reply-To: <43714EFB.5070705@etek.chalmers.se>
Add documentation for git-pack-intersect
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
Documentation/git-pack-intersect.txt | 47 ++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-pack-intersect.txt
applies-to: 2746df1385345537edc41746b191c67ee98eea20
a1b6ab6c15c3b782478a524a7fd7791ba92960e6
diff --git a/Documentation/git-pack-intersect.txt b/Documentation/git-pack-intersect.txt
new file mode 100644
index 0000000..a73d9e3
--- /dev/null
+++ b/Documentation/git-pack-intersect.txt
@@ -0,0 +1,47 @@
+git-pack-intersect(1)
+=====================
+
+NAME
+----
+git-pack-intersect - Program used to find redundant pack files.
+
+
+SYNOPSIS
+--------
+'git-pack-intersect [ -v ] < -a | .pack filename ... >'
+
+DESCRIPTION
+-----------
+This program computes which packs in your repository
+are redundant. The output is suitable for piping to
+'xargs rm' if you are in the root of the repository.
+
+OPTIONS
+-------
+
+-v::
+ Verbose. Outputs some statistics to stderr.
+ Has a small performance penalty.
+
+-a::
+ All. Processes all the local packs. Any filenames on
+ the commandline are ignored.
+
+Author
+------
+Written by Lukas Sandström <lukass@etek.chalmers.se>
+
+Documentation
+--------------
+Documentation by Lukas Sandström <lukass@etek.chalmers.se>
+
+See-Also
+--------
+gitlink:git-pack-objects[1]
+gitlink:git-repack[1]
+gitlink:git-prune-packed[1]
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
---
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