* [KORG] kernel.org/git/ showing nothing
From: Jeff Garzik @ 2006-08-04 10:25 UTC (permalink / raw)
To: ftpadmin; +Cc: Git Mailing List
When I visit http://www.kernel.org/git/ no projects at all are listed.
At least one other person independently noted this, as well.
Jeff
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-08-04 10:12 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
Since it was tagged as 1.4.2-rc3, it has acquired a couple of
further fixes. Hopefully there won't be anything but fixes on
this branch until the real 1.4.2 happens.
- Documentation, usage string fixes and general clean-ups
everywhere by Jeff King, Ramsay Allan Jones, Uwe Zeisberger,
and Matthias Lederhofer.
- A few more commands are made built-ins by Matthias
Kestenholz.
- A minor memory leak in git-tar-tree was plugged by Rene
Scharfe.
- Ramsay Allan Jones has introduced "NO_C99_FORMAT" Makefile
variable to help running things with a C library that does
not support %zu and %td format. This would be a good target
for autoconf work by Jakub (hint hint).
- To make it easy to tell which side of the connection the
errors happened while fetching/pulling, messages from the
remote side are prefixed with "remote: ".
- "git diff blob1 blob2" were showing the patch in reverse,
and did not identify blob names of both sides. Fixed.
- "git commit -o path" from subdirectories were broken when
git-read-tree became a built-in. Fixed.
* The 'next' branch, in addition, has these.
- A big gitweb clean-up series by Jakub Narebski, with help
from Jeff King, Matthias Lederhofer and Martin Waitz to make
run-time and build-time configuration easier.
- Jakub Narebski made config.mak.autogen to tell where Perl
and Python are to the build system.
- Not-universally-liked Git.pm by Pasky with help from Dennis
Stosberg, Johannes Schindelin, Pavel Roskin and others.
One drawback is this pretty much makes Perl scripts that use
Git.pm unusable with ActiveState right now.
- A new merge strategy, merge-recur, which is a rewrite of
merge-recursive in C, by Johannes and Alex.
- More commands are made built-in by Matthias Kestenholz, and
I cleaned up the build procedure for built-ins a bit.
- New style loose objects, which use the same header format as
in-pack objects, can be copied straight into packs when not
deltified. Note that new-style loose objects are not
enabled by default yet.
- Matthias Lederhofer introduced $GIT_PAGER environment
variable that can specify a different pager from $PAGER.
- I suspect Cygwin needs NO_C99_FORMAT. Confirmation is
appreciated.
- Ramsay Allan Jones has one header fix to add _GNU_SOURCE,
which helps things to compile in his environment; this needs
to be checked to make sure it does not break others.
- Timo Hirvonen made the parameter parsing of diff family
saner some time ago. Two minor changes are waiting to
graduate to "master" after 1.4.2:
* --name-only, --name-status, --check and -s are mutually exclusive
* Remove awkward compatibility warts "-s". Now -s means "do
not output diff" everywhere, including git-diff-files.
* The 'pu' branch, in addition, has these.
- Johannes Schindelin has a new diff option --color-words to
use color to squash word differences into single line
output.
- An update to upload-pack to prevent it from going all the
way back when the downloader has more roots than it. Needs
testing and comments.
- A new merge strategy, merge-rename, which is still a
work-in-progress to handle renames in read-tree 3-way
merge.
^ permalink raw reply
* [PATCH] git-tar-tree: fix minor memory leak
From: Rene Scharfe @ 2006-08-04 8:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Free the root tree object buffer when we're done, plugging a minor leak
in generate_tar(). Note: we cannot simply free(tree.buf) because this
pointer is modified by tree_entry() calls in traverse_tree().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
My first Valgrind run. :)
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index 7c48db9..215892b 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -314,6 +314,7 @@ static int generate_tar(int argc, const
struct commit *commit;
struct tree_desc tree;
struct strbuf current_path;
+ void *buffer;
current_path.buf = xmalloc(PATH_MAX);
current_path.alloc = PATH_MAX;
@@ -341,8 +342,8 @@ static int generate_tar(int argc, const
} else
archive_time = time(NULL);
- tree.buf = read_object_with_reference(sha1, tree_type, &tree.size,
- tree_sha1);
+ tree.buf = buffer = read_object_with_reference(sha1, tree_type,
+ &tree.size, tree_sha1);
if (!tree.buf)
die("not a reference to a tag, commit or tree object: %s",
sha1_to_hex(sha1));
@@ -351,6 +352,7 @@ static int generate_tar(int argc, const
write_entry(tree_sha1, ¤t_path, 040777, NULL, 0);
traverse_tree(&tree, ¤t_path);
write_trailer();
+ free(buffer);
free(current_path.buf);
return 0;
}
^ permalink raw reply related
* [PATCH] Document rev-list's option --mergegit@vger.kernel.org
From: Uwe Zeisberger @ 2006-08-04 8:11 UTC (permalink / raw)
To: git
Signed-off-by: Uwe Zeisberger <Uwe_Zeisberger@digi.com>
---
The description is not very verbose, but at least it is mentioned now.
Documentation/git-rev-list.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index f60eacd..dd9fff1 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -22,6 +22,7 @@ SYNOPSIS
[ [\--objects | \--objects-edge] [ \--unpacked ] ]
[ \--pretty | \--header ]
[ \--bisect ]
+ [ \--merge ]
<commit>... [ \-- <paths>... ]
DESCRIPTION
@@ -123,6 +124,10 @@ OPTIONS
topological order (i.e. descendant commits are shown
before their parents).
+--merge::
+ After a failed merge, show refs that touch files having a
+ conflict and don't exist on all heads to merge.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
--
1.4.2.rc2.gb63f
--
Uwe Zeisberger
FS Forth-Systeme GmbH, A Digi International Company
Kueferstrasse 8, D-79206 Breisach, Germany
Phone: +49 (7667) 908 0 Fax: +49 (7667) 908 200
Web: www.fsforth.de, www.digi.com
^ permalink raw reply related
* Re: [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution - take 2
From: Alex Riesen @ 2006-08-04 8:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11546518271379-git-send-email-martin@catalyst.net.nz>
On 8/4/06, Martin Langhoff <martin@catalyst.net.nz> wrote:
> This is a bit of a crude but really useful shortcut for conflict resolution.
> The name is bad, but git-merge-* is a different 'namespace', and git-resolve is
> also taken.
git-xxmerge?
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Marc Singer @ 2006-08-04 7:30 UTC (permalink / raw)
To: git
In-Reply-To: <20060803235536.GJ17966@craic.sysops.org>
I found that lighttpd works well, though the configuration was a
little more complex.
The recipe that works well is to make the URL
http://server/git
to the gitweb.cgi script. I put the script and the CSS file in a
directory, /var/lib/git/, and then put the following into the lighttpd
configuration:
# Serve GIT
url.redirect = ( "^/git$" => "/git/" )
alias.url += ( "/git/" => "/var/lib/git/" )
$HTTP["url"] =~ "^/git/" {
cgi.assign = ( ".cgi" => "" )
index-file.names = ( "gitweb.cgi" )
}
Cheers.
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Marc Singer @ 2006-08-04 6:11 UTC (permalink / raw)
To: Francis Daly; +Cc: git, Blu Corater
In-Reply-To: <20060803235536.GJ17966@craic.sysops.org>
On Fri, Aug 04, 2006 at 12:55:36AM +0100, Francis Daly wrote:
> > Marc Singer wrote:
> > On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
>
> Hi there,
>
> > > If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> > > index page. Only if I request http://server/~blu/scm/, Cherokee returns
> > > the expected output from gitweb.
>
> This is due to one apparent bug in Cherokee's Directory handling.
>
> > I can see the project overview page, but all of the links bring me
> > back to the same top-level page, no summary, not logs. I've verified
> > that the web server's user can read the git repo.
>
> And this is due a a different, but arguably related, one. (The 301
> handler ignores things it shouldn't.)
>
> > I don't doubt that this is a cherokee issue.
>
> Cherokee's handling of both Directory and Request sections with cgi and
> Scriptalias seems a bit funky (in different ways). If you want to use
> Cherokee configured this way, you may find it handy to add
>
> $my_uri .= '/';
> to your version of gitweb.cgi shortly after it is set -- that should
> break most of the generated links in a way that causes them to work with
> this server.
>
> $my_url is only used in a few places, but it may be worth doing the same
> thing to it too.
That does it.
>
> Or use a web server which isn't broken in this particular way.
:-) There doesn't seem to be much of the 'small' variety. Though now
I'll look into lighttpd as well.
>
> Good luck,
Cheers.
^ permalink raw reply
* Re: Creating objects manually and repack
From: Jon Smirl @ 2006-08-04 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0608032150510.4168@g5.osdl.org>
On 8/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 3 Aug 2006, Linus Torvalds wrote:
> >
> > Sure. In that case, just list the object ID's in the exact same order you
> > created them.
>
> Btw, you still want to give a filename for each object you've created, so
I'll add a file name hint.
I'm converting the cvs2svn tool to do cvs2git.
Martin has a copy of it up under git. I haven't checked in any of my
changes yet.
http://git.catalyst.net.nz/gitweb?p=cvs2svn.git;a=summary
If you read the log it is obvious that these guys have done major work
to deal with all kinds of broken CVS repositories. I want to piggyback
on that work and reuse their code that builds change sets. So far
this is the only tool I have found that can import the Mozilla CVS
without errors. Only problem is that it imports it to SVN instead of
git. I'm fixing that and learning Python at the same time.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Creating objects manually and repack
From: Linus Torvalds @ 2006-08-04 5:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0608032138330.4168@g5.osdl.org>
On Thu, 3 Aug 2006, Linus Torvalds wrote:
>
> Sure. In that case, just list the object ID's in the exact same order you
> created them.
Btw, you still want to give a filename for each object you've created, so
that the delta sorter does the right thing for the packing. It doesn't
have to be a _real_ filename - just make sure that each revision that
comes from the same file has a filename that matches all the other
revisions from that file.
What the filename actually _is_ doesn't much matter, and it doesn't have
to be the "real" filename that was associated with that set of revisions,
since we'll just end up hashing it anyway. So it could be some "SVN inode
number" for that set of revisions or something, for all git-pack-object
cares.
So you could just go through each SVN file in whatever the SVN database is
(I don't know how SVN organizes it), generate every revisions for that
file, and pass in the SVN _database_ filename, rather than necessarily the
filename that that revision is actually associated with when checked out.
So for example, if SVN were to use the same kind of "Attic/filename,v"
format that CVS uses, there's no reason to worry what the real filename
was in any particular checked out tree, you could just pass
git-pack-objects a series of lines in the form of
..
<sha1-object-name-of-rev1> Attic/filename,v
<sha1-object-name-of-rev2> Attic/filename,v
<sha1-object-name-of-rev3> Attic/filename,v
..
as input on its stdin, and it will create a pack-file of all the objects
you name, and use the "Attic/filename,v" info as the deltifier hint to
know to do all the deltas of those revs against each other rather than
against random other objects.
The fact that the file was actually checked out as "src/filename" (and,
since SVN supports renaming, it might have been checked out under any
number of _other_ names over the history of the project) doesn't matter,
and you don't need to even try to figure that out. git-pack-objects
wouldn't care anyway.
Linus
^ permalink raw reply
* Re: Creating objects manually and repack
From: Linus Torvalds @ 2006-08-04 4:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608032124o5b5b69b5hda2eb8cb1e0ac959@mail.gmail.com>
On Fri, 4 Aug 2006, Jon Smirl wrote:
>
> I am converting all of the revisions from each CVS file into git
> objects the first time the file is parsed. The plan was to run repack
> after each file is finished. That way it should be easy to figure out
> the deltas since everything will be a variation on the same file.
Sure. In that case, just list the object ID's in the exact same order you
created them.
Basically,as you create them, just keep a list of all ID's you've created,
and every (say) 50,000 objects, just do a
echo all objects you've created | git-pack-objects new-pack
and then move the new pack into place, and remove all the loose objects
(don't even bother using "git prune" - just basically do something like
"rm -rf .git/objects/??" to get rid of them).
> So what's the best way to pack these objects, append them to the
> existing pack and then clean everything up for the next file? I am
> parsing 120K CVS files containing over 1M revs.
You'll want to repack every once in a while just to not ever have _tons_
of those loose objects around, but if you do it every 50,000 objects,
you'll have just twenty nice pack-files once you're done, containing all
one million objects, and you'll never have had more than ~200 files in any
of the loose object subdirectories.
Of course, you might want to make that "every 50,000 object" thing
tunable, so that if you don't have a lot of memory for caching, you might
want to do it a bit more often just to make each repack go faster and not
have tons of IO.
You can then do a _full_ repack to get one big object, by just listing
every object you ever created (in creation order) to git-pack-objects, and
then you can replace all the twenty (smaller) pack-files with the
resulting single bigger one.
In fact, at that point you no longer even need to worry about "creation
order", since you've basically created all the deltas in the first phase,
and regardless of ordering, when you then repack everything at the end, it
will re-use all earlier delta information.
Linus
^ permalink raw reply
* Re: [PATCH 9/10] Remove cmd_usage() routine and re-organize the help/usage code.
From: Junio C Hamano @ 2006-08-04 4:33 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git
In-Reply-To: <000101c6b72a$51601a80$c47eedc1@ramsay1.demon.co.uk>
"Ramsay Jones" <ramsay@ramsay1.demon.co.uk> writes:
> Speaking of consistency, I noticed some inconsistent command
> names in various usage strings. I attach a patch (p0011.txt)
> for your consideration.
Thanks, all look good.
> During one of my "grep-fests", I also noticed some calls to
> die(usage_string) rather than usage(usage_string). Calling die()
> rather than usage() means that a "fatal: " (rather than "usage: ")
> prefix is output prior the usage string, and the exit code
> is 128 (rather than 129).
>
> It looks like to choice of die() was deliberate, particularly in
> builtin-rm.c and hash-object.c since they call both die() and
> usage(). However, It's not clear to me why this choice was made.
> (Which is not to say there isn't a perfectly good reason for the
> choice; it's just that I don't see it.)
I think these were all sloppy coding. The fix you did with
p0012 look good -- all of them are complaining that the command
line parsing found something unexpected, so I think usage() is
more appropriate.
^ permalink raw reply
* Re: Regression: git-commit no longer works from within subdirectories
From: Junio C Hamano @ 2006-08-04 4:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060803202957.GA26838@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The culprit is the recent changes to the builtins. cmd_read_tree now
> takes an extra parameter 'prefix' which shadows the global declaration
> in builtin-read-tree.c (and has a completely different meaning).
Thanks -- well spotted. And of course "next" does not suffer
because the prefix global is gone and is replaced with a member
of a structure that is given as a parameter.
^ permalink raw reply
* Re: Creating objects manually and repack
From: Jon Smirl @ 2006-08-04 4:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0608032052210.4168@g5.osdl.org>
I am converting all of the revisions from each CVS file into git
objects the first time the file is parsed. The plan was to run repack
after each file is finished. That way it should be easy to figure out
the deltas since everything will be a variation on the same file.
So what's the best way to pack these objects, append them to the
existing pack and then clean everything up for the next file? I am
parsing 120K CVS files containing over 1M revs.
After I get all of the objects written and packed later code is going
to write out the trees.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Creating objects manually and repack
From: Linus Torvalds @ 2006-08-04 4:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608032043u689f431rc5408c6d89398142@mail.gmail.com>
On Thu, 3 Aug 2006, Jon Smirl wrote:
>
> I've made 500K object files with my cvs2svn front end. This is 500K of
> revision files and no tree files. Now I run get-repack. It says done
> counting zero objects. What needs to be update so that repack will
> find all of my objects?
Just enumerate them by hand, and pass the list off to git-pack-objects.
IOW, you can _literally_ do something like this
(cd .git/objects ; find . -type f -name '[0-9a-f]*' | tr -d '\./') |
git-pack-objects tmp-pack
and it will generate a pack-file and index (called "tmp-pack-*.pack" and
"tmp-pack-*.idx" respectively) that contains all your lose objects.
Now, that said, pack-file will generally _suck_ if you actually do it like
the above. You actually want to pass in the object names _together_ with
the filenames they were generated from, so that git-pack-objects can use
its heuristics for finding good delta candidates.
So what you actually want to do is pass in a set of object names with the
name of the file they came with (space in between). See for example
git-rev-list --objects HEAD^..
output for how something like that might look (git-pack-objects is
designed to take the "git-rev-list --objects" output as its input).
> git-fsck isn't happy either since I have no HEAD.
Yeah, you cannot (and mustn't) run anything like git-fsck-objects or "git
prune" until you've connected them all up somehow.
Linus
^ permalink raw reply
* Re: Creating objects manually and repack
From: Jeff King @ 2006-08-04 3:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910608032043u689f431rc5408c6d89398142@mail.gmail.com>
On Thu, Aug 03, 2006 at 11:43:42PM -0400, Jon Smirl wrote:
> I've made 500K object files with my cvs2svn front end. This is 500K of
> revision files and no tree files. Now I run get-repack. It says done
> counting zero objects. What needs to be update so that repack will
> find all of my objects?
git-repack starts at your heads and works its way down. You can either:
- make a dummy commit for a tree with all of your blobs:
$ while read sha1; do
echo -e "100644 blob $sha1\t$sha1"
done <list_of_sha1s | git-update-index --index-info
tree=$(git-write-tree)
commit=$(git-commit-tree $tree)
git-update-ref HEAD $commit
- call git-pack-objects directly with a list of objects
git-pack-objects .git/objects/pack/pack <list_of_sha1s
Obviously the latter is simpler, but the former will also make
git-fsck-objects happy. Note that they're both untested, so there might
be typos.
-Peff
^ permalink raw reply
* Re: [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution
From: Martin Langhoff (CatalystIT) @ 2006-08-04 3:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060804033144.GB24818@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Aug 04, 2006 at 12:37:44PM +1200, Martin Langhoff (CatalystIT) wrote:
>
>
>>>instead check for stage 2 ("ours") for the path.
>>
>>Reading Documentation/git-read-tree.txt it seems to mean that stage 1 is
>>merge base, 1 is ours and 2 is the branch being merged in.
>>
>>I am confused...
>>
>>Quote:
>>
>>>When performing a merge of another
>>>branch into the current branch, we use the common ancestor tree
>>>as <tree1>, the current branch head as <tree2>, and the other
>>>branch head as <tree3>.
>
>
> Look further down:
> OK, this all sounds like a collection of totally nonsensical rules,
> but it's actually exactly what you want in order to do a fast
> merge. The different stages represent the "result tree" (stage 0,
> aka "merged"), the original tree (stage 1, aka "orig"), and the two
> trees you are trying to merge (stage 2 and 3 respectively).
Grr. I just re-read my own email, and I can't believe how stupid my
question was. Still, git-xxdiff is doing the right thing, stage 2 is
"ours" and stage 3 is "branch we are merging in".
cheers,
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Creating objects manually and repack
From: Jon Smirl @ 2006-08-04 3:43 UTC (permalink / raw)
To: git
I've made 500K object files with my cvs2svn front end. This is 500K of
revision files and no tree files. Now I run get-repack. It says done
counting zero objects. What needs to be update so that repack will
find all of my objects?
git-fsck isn't happy either since I have no HEAD.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Introducing cg-xxdiff for conflict resolution
From: Martin Langhoff @ 2006-08-04 3:34 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
This is a bit of a crude but really useful shortcut for conflict resolution.
The name is bad, but matches git-xxdiff which has been around for like... ages
As Cogito doesn't make use of the index during merges/applies, cg-xxdiff
is somewhat more brittle and cannot not help during conflict resolution when
using cg-patch.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Makefile | 3 ++-
cg-xxdiff | 33 +++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index ba9bf9a..dc21702 100644
--- a/Makefile
+++ b/Makefile
@@ -18,7 +18,8 @@ SCRIPT= cg-object-id cg-add cg-admin-lso
cg-export cg-help cg-init cg-log cg-merge cg-mkpatch cg-patch \
cg-fetch cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls cg-update \
cg cg-admin-ls cg-push cg-branch-chg cg-admin-cat cg-clean \
- cg-admin-setuprepo cg-switch cg-mv cg-admin-rewritehist cg-tag-show
+ cg-admin-setuprepo cg-switch cg-mv cg-admin-rewritehist cg-tag-show \
+ cg-xxdiff
LIB_SCRIPT=cg-Xlib cg-Xmergefile cg-Xfetchprogress cg-Xfollowrenames
diff --git a/cg-xxdiff b/cg-xxdiff
new file mode 100755
index 0000000..7a1a863
--- /dev/null
+++ b/cg-xxdiff
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+USAGE='<path-with-conflict>'
+SUBDIRECTORY_OK=No
+. git-sh-setup
+
+FILE=$1
+
+# Sanity checks
+if test ! -n "$FILE"
+then
+ echo Need a path
+ exit 1
+fi
+
+git cat-file blob `git rev-parse HEAD`:$FILE > $FILE~ours
+if test $? -gt 0
+then
+ echo "Error - $FILE is not tracked by git or does not have a conflict"
+ exit 1
+fi
+echo Written $FILE~ours
+
+git cat-file blob `git rev-parse FETCH_HEAD`:$FILE > $FILE~branch
+if test $? -gt 0
+then
+ echo "Error - $FILE is not tracked by git or does not have a conflict"
+ exit 1
+fi
+echo Written $FILE~branch
+echo Resolved file will be saved as $FILE~merged
+
+xxdiff -wbB --show-merged-pane --merged-filename $FILE~merged $FILE~ours $FILE~branch
--
1.4.2.rc2.ge1f7
^ permalink raw reply related
* Re: [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution
From: Jeff King @ 2006-08-04 3:31 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: Junio C Hamano, git
In-Reply-To: <44D296D8.4030200@catalyst.net.nz>
On Fri, Aug 04, 2006 at 12:37:44PM +1200, Martin Langhoff (CatalystIT) wrote:
> >instead check for stage 2 ("ours") for the path.
> Reading Documentation/git-read-tree.txt it seems to mean that stage 1 is
> merge base, 1 is ours and 2 is the branch being merged in.
>
> I am confused...
>
> Quote:
> >When performing a merge of another
> >branch into the current branch, we use the common ancestor tree
> >as <tree1>, the current branch head as <tree2>, and the other
> >branch head as <tree3>.
Look further down:
OK, this all sounds like a collection of totally nonsensical rules,
but it's actually exactly what you want in order to do a fast
merge. The different stages represent the "result tree" (stage 0,
aka "merged"), the original tree (stage 1, aka "orig"), and the two
trees you are trying to merge (stage 2 and 3 respectively).
HTH,
-Peff
^ permalink raw reply
* Re: [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution
From: Martin Langhoff (CatalystIT) @ 2006-08-04 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64h9pdx4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> We can have unmerged index without MERGE_HEAD (for example,
> think "rebase --merge" or "am -3"); drop check for that and
> instead check for stage 2 ("ours") for the path.
Reading Documentation/git-read-tree.txt it seems to mean that stage 1 is
merge base, 1 is ours and 2 is the branch being merged in.
I am confused...
Quote:
> When performing a merge of another
> branch into the current branch, we use the common ancestor tree
> as <tree1>, the current branch head as <tree2>, and the other
> branch head as <tree3>.
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution - take 2
From: Martin Langhoff @ 2006-08-04 0:37 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
In-Reply-To: <7v64h9pdx4.fsf@assigned-by-dhcp.cox.net>
This is a bit of a crude but really useful shortcut for conflict resolution.
The name is bad, but git-merge-* is a different 'namespace', and git-resolve is
also taken.
And as different conflict resolvers take different options, it may make sense
to have git-xxdiff, git-sdiff and git-winmerge at least initially.
Reposting with some fixes suggested by Junio.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
How about this one? ;-)
---
Makefile | 2 +-
git-xxdiff.sh | 33 +++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8349e3d..a6f6628 100644
--- a/Makefile
+++ b/Makefile
@@ -145,7 +145,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh
+ git-lost-found.sh git-quiltimport.sh git-xxdiff.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-xxdiff.sh b/git-xxdiff.sh
new file mode 100755
index 0000000..3dc9876
--- /dev/null
+++ b/git-xxdiff.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+USAGE='<path-with-conflict>'
+SUBDIRECTORY_OK=No
+. git-sh-setup
+
+FILE=$1
+
+# Sanity checks
+if test ! -n "$FILE"
+then
+ echo Need a path
+ exit 1
+fi
+
+git cat-file blob :2:$FILE > $FILE~ours
+if test $? -gt 0
+then
+ echo "Error - $FILE is not tracked by git or does not have a conflict"
+ exit 1
+fi
+echo Written $FILE~ours
+
+git cat-file blob :3:$FILE > $FILE~branch
+if test $? -gt 0
+then
+ echo "Error - $FILE is not tracked by git or does not have a conflict"
+ exit 1
+fi
+echo Written $FILE~branch
+echo Resolved file will be saved as $FILE~merged
+
+xxdiff -wbB --show-merged-pane --merged-filename $FILE~merged $FILE~ours $FILE~branch
--
1.4.2.rc2.g1869bc-dirty
^ permalink raw reply related
* RE: [PATCH 6/10] Fix header breakage with _XOPEN_SOURCE.
From: Johannes Schindelin @ 2006-08-04 0:19 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, git
In-Reply-To: <001d01c6b664$285ff540$c47eedc1@ramsay1.demon.co.uk>
Hi,
On Wed, 2 Aug 2006, Ramsay Jones wrote:
> [...] but strptime() remains undeclared.
Note that there is just one call to strptime() in the C sources:
convert-objects.
Also, we have something more portable in git now: you might be able to
substitute
const char *next = strptime(buf, *fmt, &tm);
if (next) {
by something like
char buffer[50];
int len = parse_date(buf, buffer, sizeof(buffer));
const char *next = buf + len;
if (len) {
const char *tzstring = strchr(buffer, ' ') + 1;
int tz = (int)strtol(tzstring, NULL, 10);
tm = *time_to_tm(strtoul(buffer, NULL, 10), tz);
However, I did not test it, and this might be completely bogus.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution
From: Martin Langhoff (CatalystIT) @ 2006-08-04 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64h9pdx4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>diff --git a/git-xxdiff.sh b/git-xxdiff.sh
>>new file mode 100755
>>index 0000000..d562ab2
>>--- /dev/null
>>+++ b/git-xxdiff.sh
>>@@ -0,0 +1,38 @@
>>+#!/bin/sh
>>+
>>+USAGE='<path>'
>>+SUBDIRECTORY_OK=No
>>+. git-sh-setup
>>+
>>+FILE=$1
>>+MERGE_HEAD=`git rev-parse MERGE_HEAD`
>>+
>>+# Sanity checks
>
>
> We can have unmerged index without MERGE_HEAD (for example,
> think "rebase --merge" or "am -3"); drop check for that and
> instead check for stage 2 ("ours") for the path.
>
> git cat-file blob :2:$FILE
(didn't know the :$stage: trick, neat)
I did think of using merge stages but I wasn't sure whether all the
merge strategies followed the same convention. I'll fix up and re-post it.
> Can xxdiff take more than one file pairs?
Not that I can see.
>>+xxdiff -wbB --show-merged-pane --merged-filename $FILE~merged $FILE~HEAD $FILE~MERGE_HEAD
>>\ No newline at end of file
>
> ;-).
Ouch, yes, I forgot the newline. Grumble.
I am also telling xxdiff to save the merged file as ~merged rather than
overwriting the merge attempt that git has made. Better safe than sorry.
cheers,
m
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution
From: Junio C Hamano @ 2006-08-04 0:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <11546492331601-git-send-email-martin@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz> writes:
> diff --git a/git-xxdiff.sh b/git-xxdiff.sh
> new file mode 100755
> index 0000000..d562ab2
> --- /dev/null
> +++ b/git-xxdiff.sh
> @@ -0,0 +1,38 @@
> +#!/bin/sh
> +
> +USAGE='<path>'
> +SUBDIRECTORY_OK=No
> +. git-sh-setup
> +
> +FILE=$1
> +MERGE_HEAD=`git rev-parse MERGE_HEAD`
> +
> +# Sanity checks
We can have unmerged index without MERGE_HEAD (for example,
think "rebase --merge" or "am -3"); drop check for that and
instead check for stage 2 ("ours") for the path.
git cat-file blob :2:$FILE
Can xxdiff take more than one file pairs?
If so you might want to list unmerged paths (ls-files -u) and
iterate through it when no paths are given from the command
line. If not, you might want to take the first unmerged path
when no paths are given from the command line.
> +xxdiff -wbB --show-merged-pane --merged-filename $FILE~merged $FILE~HEAD $FILE~MERGE_HEAD
> \ No newline at end of file
;-).
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Francis Daly @ 2006-08-03 23:55 UTC (permalink / raw)
To: git; +Cc: Blu Corater, Marc Singer
In-Reply-To: <20060803202703.GA13147@buici.com>
> Marc Singer wrote:
> On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
Hi there,
> > If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> > index page. Only if I request http://server/~blu/scm/, Cherokee returns
> > the expected output from gitweb.
This is due to one apparent bug in Cherokee's Directory handling.
> I can see the project overview page, but all of the links bring me
> back to the same top-level page, no summary, not logs. I've verified
> that the web server's user can read the git repo.
And this is due a a different, but arguably related, one. (The 301
handler ignores things it shouldn't.)
> I don't doubt that this is a cherokee issue.
Cherokee's handling of both Directory and Request sections with cgi and
Scriptalias seems a bit funky (in different ways). If you want to use
Cherokee configured this way, you may find it handy to add
$my_uri .= '/';
to your version of gitweb.cgi shortly after it is set -- that should
break most of the generated links in a way that causes them to work with
this server.
$my_url is only used in a few places, but it may be worth doing the same
thing to it too.
Or use a web server which isn't broken in this particular way.
Good luck,
f
--
Francis Daly francis@daoine.org
^ 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