* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Jason Riedy @ 2005-12-06 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtih299f.fsf@assigned-by-dhcp.cox.net>
And Morten Welinder writes:
- The code looks wrong. It assumes that pointers are no larger than ints.
The failure's in 32-bit mode, so they _are_ the same size.
The difference is no more than 0x80 in the tests.
But you're right; the result is implementation defined in
C99.
And Junio C Hamano writes:
- Are you suggesting it to be done like this?
Your change fixed it. Oddly enough, using arithmetic in
ptrdiff_t then testing against zero didn't... I don't
have time to dig through assembly or try different gcc
versions to figure out the real problem. ugh.
Jason
^ permalink raw reply
* A list of things missing or wrong in the documentation
From: Nikolai Weibull @ 2005-12-06 22:12 UTC (permalink / raw)
To: GIT Mailing List
Here's a list of things that are missing, wrong, or badly formatted in
the documentation (all checked against the man pages):
git-checkout-index:
SYNOPSIS:
--index
--quiet
--force
--all
--no-create
(How do we put these in the SYNOPSIS?)
(My bad, forgot to mention this in an earlier patch.)
git-read-tree:
--trivial
SYNOPSIS:
--reset
git-update-index:
-h
--help
(perhaps redundant)
git-rev-list:
--dense
--no-merges
git-merge-base:
-a, --all
git-verify-pack:
--
git-http-fetch:
commit-id and url are missing descriptions
git-update-server-info:
-f
git-am:
--utf8 is converted to -u
--keep is converted to -k
git-bisect:
Documentation is messed up. Lines are being joined when they
shouldn't be (put "+ " at end of line).
git-cherry-pick:
--no-commit
--replay
git-clone:
SYNOPSIS:
--local
--shared
--quiet
--upload-pack
git-commit:
--all
--signoff
--verify
--no-verify
--edit
-n
git-diff:
--diff-options should be <common diff options>
The table isn't rendered properly in the man-page. I'm guessing
that this is a problem with my DocBook templates, but I wanted
to check if anyone else has this issue.
git-format-patch:
SYNOPSIS:
provide spacing around options, like other man-pages
--keep-subject
--numbered
--output-directory
-h --help
-m
-d
git-ls-remote:
-h
-t
git-pull:
--strategy
git-repack:
-n
-l
git-revert:
--no-commit
-r --replay
git-show-branch:
--topo-order
git-cvsimport:
error in spacing (-P)
git-prune:
--
git-tag:
doesn't follow the format of the other manual pages
missing explicit documentation for many options
General:
The term "commit-id" isn't listed in the glossary. Should this
be changed to "commit" instead?
Style guides generally suggest putting a comma after "e.g." and
"i.e.", i.e., "e.g.," and "i.e.,". It's perhaps a bit anal, but
what do you think?
rev is used as a term in some places. Should perhaps expand it
to revision?
I should of course provide patches for this, but I'm quite a bit under
the weather at the moment, and as a 1.0.0 release draws near I figured
that it'd be best that people at least know what I know so that they may
do something about it. (Also, someone with better knowledge of asciidoc
and git itself would probably do a better job than I could.)
nikolai
--
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
^ permalink raw reply
* Re: type_size_sort
From: Junio C Hamano @ 2005-12-06 21:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <439604DF.5010603@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> It's perfectly correct. If the same list was to be passed to
> create_sorted_list() twice it will come out exactly the same the second
> time as it did the first. The only thing to remark on is that the return
> above could be written as below instead:
>
> return a - b;
And I suspect Morten would say the same thing about ptrdiff_t
could be larger than an int.
I personally feel this would not make any practical difference
on sane architectures either way, though..
^ permalink raw reply
* Re: type_size_sort
From: Junio C Hamano @ 2005-12-06 21:45 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0512061319l3726fdfbs8286e7b3f5ab0713@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
> static int type_size_sort(const struct object_entry *a, const struct
> object_entry *b)
> {
> ...
> return a < b ? -1 : (a > b);
> }
>
> This does not look valid.
Then something like this?
---
diff --git a/pack-objects.c b/pack-objects.c
index a62c9f8..c27fee5 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -296,7 +296,7 @@ static int type_size_sort(const struct o
return -1;
if (a->size > b->size)
return 1;
- return a < b ? -1 : (a > b);
+ return memcmp(a->sha1, b->sha1, 20);
}
struct unpacked {
^ permalink raw reply related
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Junio C Hamano @ 2005-12-06 21:41 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0512061310r6398f812ia47a84d3cfad1564@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
> The code looks wrong. It assumes that pointers are no larger than ints.
> If pointers are larger than ints, the code does not necessarily compute
> a consistent ordering and qsort is allowed to do whatever it wants.
>
> Morten
>
>
>
> static int compare_object_pointers(const void *a, const void *b)
> {
> const struct object * const *pa = a;
> const struct object * const *pb = b;
> return *pa - *pb;
> }
Are you suggesting it to be done like this?
---
git diff
diff --git a/object.c b/object.c
index 427e14c..dac5c92 100644
--- a/object.c
+++ b/object.c
@@ -82,7 +82,12 @@ static int compare_object_pointers(const
{
const struct object * const *pa = a;
const struct object * const *pb = b;
- return *pa - *pb;
+ if (*pa == *pb)
+ return 0;
+ else if (*pa < *pb)
+ return -1;
+ else
+ return 1;
}
void set_object_refs(struct object *obj, struct object_refs *refs)
^ permalink raw reply related
* Re: type_size_sort
From: Andreas Ericsson @ 2005-12-06 21:38 UTC (permalink / raw)
To: GIT Mailing List
In-Reply-To: <118833cc0512061319l3726fdfbs8286e7b3f5ab0713@mail.gmail.com>
Morten Welinder wrote:
> static int type_size_sort(const struct object_entry *a, const struct
> object_entry *b)
> {
> ...
> return a < b ? -1 : (a > b);
> }
>
> This does not look valid. the standard says you must not depend on the
> location:
>
>
> [#4] When the same objects (consisting of size bytes,
> irrespective of their current positions in the array) are
> passed more than once to the comparison function, the
> results shall be consistent with one another. That is, for
> qsort they shall define a total ordering on the array, and
> for bsearch the same object shall always compare the same
> way with the key.
>
It's perfectly correct. If the same list was to be passed to
create_sorted_list() twice it will come out exactly the same the second
time as it did the first. The only thing to remark on is that the return
above could be written as below instead:
return a - b;
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git shorthands (was: Re: Wine + GIT)
From: Andreas Ericsson @ 2005-12-06 21:22 UTC (permalink / raw)
To: Git List
In-Reply-To: <1133891589.8577.63.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
>
> That way:
> "git mer" would fail
> "git merge" would run "git-merge"
> "git merge-" would fail
> "git merge-o" would fail,
> "git-merge-oc" would run "git-merge-octopus".
>
> Any interest? Overkill? Bad idea?
>
I think it's overkill. It would be better, methinks, to add mnemonic-ish
shorthands for the porcelainish commands, so that
git fp => git-format-patch
git co => git-checkout
git up => git-update-index
git octo => git-merge-octopus
git fsck => git-fsck-objects
git hash => git-hash-object
and so on...
This because non-ambiguous is rarely logical (for git at least, which
has 'git-<family>-<action | object-type>) unless one knows the entire
command anyways. Ambiguity may also be introduced by later commands, and
then you'll need to re-learn them. I always find that annoying.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* ssh removed?
From: Nico -telmich- Schottelius @ 2005-12-06 21:19 UTC (permalink / raw)
To: git list
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
Moin!
Did somebody remove git+ssh in git? If I search for ssh in cg-log
in the git source I do not see any hint. But I see that when trying to
use it:
[22:15] hydrogenium:ccollect.sh% git-init-db
defaulting to local storage area
[22:15] hydrogenium:ccollect.sh% cg-branch-add creme git+ssh://creme.schottelius.org/home/server/git/cLinux/ccollect.git
[22:15] hydrogenium:ccollect.sh% cg-fetch creme
Fetching pack (head and objects)...
fatal: I don't handle protocol 'git+ssh'
cg-fetch: fetching pack failed
[22:16] hydrogenium:ccollect.sh% cg-version
cogito-0.17pre.GIT (c10cc1d2a99b01ed3bf45d5f2ad6157940a22365)
[22:17] hydrogenium:ccollect.sh% git --version
git version 0.99.8.GIT
Just a little bit confused,
Nico
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* type_size_sort
From: Morten Welinder @ 2005-12-06 21:19 UTC (permalink / raw)
To: GIT Mailing List
static int type_size_sort(const struct object_entry *a, const struct
object_entry *b)
{
...
return a < b ? -1 : (a > b);
}
This does not look valid. the standard says you must not depend on the
location:
[#4] When the same objects (consisting of size bytes,
irrespective of their current positions in the array) are
passed more than once to the comparison function, the
results shall be consistent with one another. That is, for
qsort they shall define a total ordering on the array, and
for bsearch the same object shall always compare the same
way with the key.
M.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Morten Welinder @ 2005-12-06 21:10 UTC (permalink / raw)
To: Jason Riedy; +Cc: Junio C Hamano, git
In-Reply-To: <14331.1133899163@lotus.CS.Berkeley.EDU>
The code looks wrong. It assumes that pointers are no larger than ints.
If pointers are larger than ints, the code does not necessarily compute
a consistent ordering and qsort is allowed to do whatever it wants.
Morten
static int compare_object_pointers(const void *a, const void *b)
{
const struct object * const *pa = a;
const struct object * const *pb = b;
return *pa - *pb;
}
^ permalink raw reply
* Re: announce: git browser
From: Junio C Hamano @ 2005-12-06 20:23 UTC (permalink / raw)
To: Artem Khodush; +Cc: git
In-Reply-To: <40b2b7d90512060013j23345bf3o2021080edcfbd9c0@mail.gmail.com>
Artem Khodush <greenkaa@gmail.com> writes:
> And the reason why special NNTP server is needed is, I guess,
> that plain NNTP server will not be able to cope with all the diffs
> stored in message database? Well, but then, the newsgroups
> will not be distributable..
>
> Or is there any other reason?
Actually, the real reason was I was stupid (I am always stupid
but I was more stupid than I usually am in this case). We could
just inject new patches into appropriate newsgroups as they come
along, either from a cron job or from the post-update hook.
^ permalink raw reply
* Re: [PATCH] Add compat/setenv.c, use in git.c.
From: Jason Riedy @ 2005-12-06 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslt67v9o.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- I'd like to throw in another Makefile patch to catch both 5.8 and
- 5.9 for this, but would appreciate if people with various vintage
- of Solaris boxes can give some inputs before doing that.
Anyone else seeing the qsort in object.c trash memory? The
input _looks_ correct. I only see this on Solaris (8), but
I've never had a problem with qsort there. I think we have
a Solaris 9 box around here somewhere, but probably only
partially 9. The admins here are too busy fixing Windows to
maintain anything else properly.
- This was done with somewhat stripped down configuration.
Once I replace the qsort (with an insertion sort), almost all
the tests work with my odd-ball but full configuration. I'm
having some problems with cpio in the push tests, but it's
just some path issue for my setup. When I run the same
commands by hand, they work.
I'll test this on AIX again soon.
Jason
^ permalink raw reply
* Re: Wine + GIT
From: Mike McCormack @ 2005-12-06 19:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: J. Bruce Fields, git
In-Reply-To: <4395E01D.4080107@pobox.com>
Jeff Garzik wrote:
> In general, there is not much difference, except that I was admonished
> to avoid the git-XXX in my howto. I suppose that makes sense if the
> git-XXX programs are moved out of $prefix/bin, leaving only
> $prefix/bin/git.
Using the git-* commands means that tab completion works, which is good
for impatient people with bad memories, like myself :)
Mike
^ permalink raw reply
* Re: Wine + GIT
From: Jeff Garzik @ 2005-12-06 19:01 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Mike McCormack, git
In-Reply-To: <20051206170803.GD17457@fieldses.org>
J. Bruce Fields wrote:
> On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:
>
>>2) The "git-foo" commands are apparently uncool. "git foo ..." is
>>preferred.
>
>
> How does e.g. git-diff differ from git diff? I thought they were
> equivalent.--b.
The specific git-diff-XXX command example was longer.
In general, there is not much difference, except that I was admonished
to avoid the git-XXX in my howto. I suppose that makes sense if the
git-XXX programs are moved out of $prefix/bin, leaving only $prefix/bin/git.
Jeff
^ permalink raw reply
* Re: Wine + GIT
From: Jon Loeliger @ 2005-12-06 17:53 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git List
In-Reply-To: <20051206173909.GE17457@fieldses.org>
On Tue, 2005-12-06 at 11:39, J. Bruce Fields wrote:
> I've enjoyed getting tab completions without having to add whatever's
> required to my .bashrc to teach it about git subcommands. Oh well,
> I'll
> get over it.
I believe this effort is already well under way.
Uh, I also thought we were going to place it in
some "contrib" directory too...?
Also, before I learned of that bash completion effort,
I was contemplating modifying the git.c command recognition
so that it effectively did this:
cmd = ... whatever from command line
if (exec(cmd)) works then
happily clean up and exit
else
using the existing directory scan as a new function,
determine if "cmd" is a proper prefix of some command,
if it is unique then
exec(unique-cmd-disambiguated)
else
complain that it is not unique
fi
fi
That way:
"git mer" would fail
"git merge" would run "git-merge"
"git merge-" would fail
"git merge-o" would fail,
"git-merge-oc" would run "git-merge-octopus".
Any interest? Overkill? Bad idea?
jdl
^ permalink raw reply
* Re: Wine + GIT
From: J. Bruce Fields @ 2005-12-06 17:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacfe2ks1.fsf@assigned-by-dhcp.cox.net>
On Tue, Dec 06, 2005 at 09:33:02AM -0800, Junio C Hamano wrote:
> There is a long time-horizon plan to move most of the things out
> of /usr/bin/, and codewise we have the infrastructure to do it
> today. The only reason we haven't done so is that it would break
> scripts written by people who learned git from documents that
> tell them to write things in dash form, "git-diff".
I've enjoyed getting tab completions without having to add whatever's
required to my .bashrc to teach it about git subcommands. Oh well, I'll
get over it.
I suppose the git-subcommand convention will continue for the purpose of
naming manpages?
--b.
^ permalink raw reply
* Re: Wine + GIT
From: Junio C Hamano @ 2005-12-06 17:33 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20051206170803.GD17457@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:
>> 2) The "git-foo" commands are apparently uncool. "git foo ..." is
>> preferred.
>
> How does e.g. git-diff differ from git diff? I thought they were
> equivalent.--b.
For now, but to futureproof your document and its readers, it is
better spelled as "git frotz" not "git-frotz".
There is a long time-horizon plan to move most of the things out
of /usr/bin/, and codewise we have the infrastructure to do it
today. The only reason we haven't done so is that it would break
scripts written by people who learned git from documents that
tell them to write things in dash form, "git-diff".
^ permalink raw reply
* Re: Cygwin test failure in t6021-merge-criss-cross.sh
From: Tim O'Callaghan @ 2005-12-06 17:10 UTC (permalink / raw)
To: git
In-Reply-To: <7v1x0q419j.fsf@assigned-by-dhcp.cox.net>
On Tue, Dec 06, 2005 at 08:51:36AM -0800, Junio C Hamano wrote:
> I have this strange feeling that you do not have "merge"
> installed on your cygwin box. It is part of "rcs".
>
Thanks, that was it. Another dependency to add to git-core :)
> When you see a test failure, it sometimes useful to try running:
>
> $ cd t
> $ sh ./t6021-*.sh -i -v
>
> manually.
>
Duly noted.
Tim.
"I've worked myself up from nothing to a state of supreme poverty."
-- Groucho Marx
^ permalink raw reply
* Re: Wine + GIT
From: J. Bruce Fields @ 2005-12-06 17:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Mike McCormack, git
In-Reply-To: <4394F173.6000505@pobox.com>
On Mon, Dec 05, 2005 at 09:03:31PM -0500, Jeff Garzik wrote:
> 2) The "git-foo" commands are apparently uncool. "git foo ..." is
> preferred.
How does e.g. git-diff differ from git diff? I thought they were
equivalent.--b.
^ permalink raw reply
* Re: Cygwin test failure in t6021-merge-criss-cross.sh
From: Junio C Hamano @ 2005-12-06 16:51 UTC (permalink / raw)
To: Tim O'Callaghan; +Cc: git
In-Reply-To: <20051206124032.GC2364@ELSAMSW37164>
I have this strange feeling that you do not have "merge"
installed on your cygwin box. It is part of "rcs".
When you see a test failure, it sometimes useful to try running:
$ cd t
$ sh ./t6021-*.sh -i -v
manually.
^ permalink raw reply
* Re: [BUG] ProgramError: merge ... .merge_file_4CPoEQ: No such file
From: Junio C Hamano @ 2005-12-06 16:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EjdPu-00034z-Hu@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> So, I was surprised by this display this morning.
> (I swear I'm trying to help! :-)
Thanks. I actually saw this myself yesterday.
I have this strange feeling that you do not have "merge"
installed on your cygwin box. It is part of "rcs".
^ permalink raw reply
* Re: [BUG] ProgramError: merge ... .merge_file_4CPoEQ: No such file
From: Jon Loeliger @ 2005-12-06 16:47 UTC (permalink / raw)
To: git
> It seems that changes has been committed to
> Documentation/git-read-tree.txt in both the jdl branch and in
> origin.
Yes.
> This shouldn't cause any problems but git-merge-recursive
> (which currently is the default merge strategy) uses merge(1) to do
> the file-level merging and it seems like merge(1) can't be found on
> your system.
>
> Do you have merge(1) installed? More appropriately, is merge in your
> path? If it isn't installed it can usually be found in the rcs package
> in your distribution.
Oh wow. Exactly correct.
Here's Jon building up the new Ubuntu box, and thinking, "I'll
be using git, so I don't need to install RCS or CVS anymore." :-)
After installing RCS, here's what we get:
jdl@ubuntu:/usr/src/git-core$ git reset --hard jdl
jdl@ubuntu:/usr/src/git-core$ git pull . origin
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with be61db922a230ae2638c27c071ee4b8c98f01f72
Merging:
4baf91676c2462796137e93917c75f2e14ebb877 Added documentation for few missing options.
be61db922a230ae2638c27c071ee4b8c98f01f72 git-merge-one-file: resurrect leading path creation.
found 1 common ancestor(s):
23c99d84601316c1e51ebc1f0b9bec5cddd011fb git-mv to work with Perl 5.6
Auto-merging Documentation/git-read-tree.txt
CONFLICT (content): Merge conflict in Documentation/git-read-tree.txt
Automatic merge failed/prevented; fix up by hand
Thanks!
jdl
^ permalink raw reply
* Re: [BUG] ProgramError: merge ... .merge_file_4CPoEQ: No such file
From: Fredrik Kuivinen @ 2005-12-06 16:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EjdPu-00034z-Hu@jdl.com>
On Tue, Dec 06, 2005 at 08:03:38AM -0600, Jon Loeliger wrote:
>
> jdl@ubuntu:/usr/src/git-core$ git pull . origin
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Merging HEAD with be61db922a230ae2638c27c071ee4b8c98f01f72
> Merging:
> 4baf91676c2462796137e93917c75f2e14ebb877 Added documentation for few missing options.
> be61db922a230ae2638c27c071ee4b8c98f01f72 git-merge-one-file: resurrect leading path creation.
> found 1 common ancestor(s):
> 23c99d84601316c1e51ebc1f0b9bec5cddd011fb git-mv to work with Perl 5.6
> Auto-merging Documentation/git-read-tree.txt
> Traceback (most recent call last):
> File "/home/jdl/bin/git-merge-recursive", line 868, in ?
> firstBranch, secondBranch, graph)
> File "/home/jdl/bin/git-merge-recursive", line 87, in merge
> branch1Name, branch2Name)
> File "/home/jdl/bin/git-merge-recursive", line 160, in mergeTrees
> if not processEntry(entry, branch1Name, branch2Name):
> File "/home/jdl/bin/git-merge-recursive", line 821, in processEntry
> branch1Name, branch2Name)
> File "/home/jdl/bin/git-merge-recursive", line 212, in mergeFile
> src1, orig, src2], returnCode=True)
> File "/home/jdl/share/git-core/python/gitMergeCommon.py", line 72, in runProgram
> raise ProgramError(progStr, e.strerror)
> ProgramError: merge -L HEAD/Documentation/git-read-tree.txt -L orig/Documentation/git-read-tree.txt -L be61db922a230ae2638c27c071ee4b8c98f01f72/Documentation/git-read-tree.txt .merge_file_DamWnQ .merge_file_U9K5YP .merge_file_4CPoEQ: No such file or directory
> No merge strategy handled the merge.
>
It seems that changes has been committed to
Documentation/git-read-tree.txt in both the jdl branch and in
origin. This shouldn't cause any problems but git-merge-recursive
(which currently is the default merge strategy) uses merge(1) to do
the file-level merging and it seems like merge(1) can't be found on
your system.
Do you have merge(1) installed? More appropriately, is merge in your
path? If it isn't installed it can usually be found in the rcs package
in your distribution.
- Fredrik
^ permalink raw reply
* [BUG] ProgramError: merge ... .merge_file_4CPoEQ: No such file
From: Jon Loeliger @ 2005-12-06 14:03 UTC (permalink / raw)
To: git
So, I was surprised by this display this morning.
(I swear I'm trying to help! :-)
I grabbed new (7:30 CST Dec 6) top-of-git, built and installed it.
I then "git checkout jdl" and "git pull . origin" to bring my
branch up to date. It looked like this just before the pull
into branch "jdl":
jdl@ubuntu:/usr/src/git-core$ git show-branch jdl master origin
* [jdl] Added documentation for few missing options.
! [master] git-merge-one-file: resurrect leading path creation.
! [origin] git-merge-one-file: resurrect leading path creation.
---
++ [master] git-merge-one-file: resurrect leading path creation.
++ [master^] Documentaiton (read-tree): update description of 3-way
++ [master~2] Documentation: hash-object.
++ [master~3] write-tree: check extra arguments and die but be a bit more helpful.
++ [master~4] init-db: check extra arguments and complain.
++ [master~5] hash-object: -- and --help
++ [master~6] Added documentation for few missing options.
+ [jdl] Added documentation for few missing options.
+ [jdl^] Merge branch 'origin'
+++ [master~7] git-mv to work with Perl 5.6
jdl@ubuntu:/usr/src/git-core$ git status
# On branch refs/heads/jdl
nothing to commit
jdl@ubuntu:/usr/src/git-core$ git pull . origin
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with be61db922a230ae2638c27c071ee4b8c98f01f72
Merging:
4baf91676c2462796137e93917c75f2e14ebb877 Added documentation for few missing options.
be61db922a230ae2638c27c071ee4b8c98f01f72 git-merge-one-file: resurrect leading path creation.
found 1 common ancestor(s):
23c99d84601316c1e51ebc1f0b9bec5cddd011fb git-mv to work with Perl 5.6
Auto-merging Documentation/git-read-tree.txt
Traceback (most recent call last):
File "/home/jdl/bin/git-merge-recursive", line 868, in ?
firstBranch, secondBranch, graph)
File "/home/jdl/bin/git-merge-recursive", line 87, in merge
branch1Name, branch2Name)
File "/home/jdl/bin/git-merge-recursive", line 160, in mergeTrees
if not processEntry(entry, branch1Name, branch2Name):
File "/home/jdl/bin/git-merge-recursive", line 821, in processEntry
branch1Name, branch2Name)
File "/home/jdl/bin/git-merge-recursive", line 212, in mergeFile
src1, orig, src2], returnCode=True)
File "/home/jdl/share/git-core/python/gitMergeCommon.py", line 72, in runProgram
raise ProgramError(progStr, e.strerror)
ProgramError: merge -L HEAD/Documentation/git-read-tree.txt -L orig/Documentation/git-read-tree.txt -L be61db922a230ae2638c27c071ee4b8c98f01f72/Documentation/git-read-tree.txt .merge_file_DamWnQ .merge_file_U9K5YP .merge_file_4CPoEQ: No such file or directory
No merge strategy handled the merge.
jdl@ubuntu:/usr/src/git-core$ ll Documentation/git-read-tree.txt .merge*
12 -rw-r--r-- 1 jdl jdl 10464 2005-12-06 07:46 Documentation/git-read-tree.txt
12 -rw------- 1 jdl jdl 11469 2005-12-06 07:47 .merge_file_4CPoEQ
12 -rw------- 1 jdl jdl 10464 2005-12-06 07:47 .merge_file_DamWnQ
12 -rw------- 1 jdl jdl 10339 2005-12-06 07:47 .merge_file_U9K5YP
jdl@ubuntu:/usr/src/git-core$ git status
# On branch refs/heads/jdl
#
# Updated but not checked in:
# (will commit)
#
# modified: Documentation/git-hash-object.txt
# modified: git-merge-one-file.sh
# modified: hash-object.c
# modified: init-db.c
# modified: write-tree.c
#
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# unmerged: Documentation/git-read-tree.txt
# modified: Documentation/git-read-tree.txt
#
#
# Untracked files:
# (use "git add" to add to commit)
#
# .merge_file_4CPoEQ
# .merge_file_DamWnQ
# .merge_file_U9K5YP
^ permalink raw reply
* Cygwin test failure in t6021-merge-criss-cross.sh
From: Tim O'Callaghan @ 2005-12-06 12:40 UTC (permalink / raw)
To: git
I tried build-testing the latest version of git, and the tests reported
this error:
---------
*** t6021-merge-criss-cross.sh ***
* FAIL 1: prepare repository
echo "1
2
3
4
5
6
7
8
9" > file &&
git add file &&
git commit -m "Initial commit" file &&
git branch A &&
git branch B &&
git checkout A &&
echo "1
2
3
4
5
6
7
8 changed in B8, branch A
9" > file &&
git commit -m "B8" file &&
git checkout B &&
echo "1
2
3 changed in C3, branch B
4
5
6
7
8
9
" > file &&
git commit -m "C3" file &&
git branch C3 &&
git merge "pre E3 merge" B A &&
echo "1
2
3 changed in E3, branch B. New file size
4
5
6
7
8 changed in B8, branch A
9
" > file &&
git commit -m "E3" file &&
git checkout A &&
git merge "pre D8 merge" A C3 &&
echo "1
2
3 changed in C3, branch B
4
5
6
7
8 changed in D8, branch A. New file size 2
9" > file &&
git commit -m D8 file
* FAIL 2: Criss-cross merge
git merge "final merge" A B
* FAIL 3: Criss-cross merge result
cmp file file-expect
* failed 3 among 3 test(s)
make[1]: *** [t6021-merge-criss-cross.sh] Error 1
make[1]: Leaving directory `/cygdrive/c/home/tim/projects/CygwinPorts/git_git/t'
make: *** [test] Error 2
----
Is there any more information i need to provide?
Tim.
"I've worked myself up from nothing to a state of supreme poverty."
-- Groucho Marx
^ 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