* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 17:11 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576F65A.6010707@xs4all.nl>
Dnia środa 6. grudnia 2006 17:56, Han-Wen Nienhuys napisał:
> Jakub Narebski escreveu:
>
>> I'm still not sure if this has place in git. Is it really common to
>> support building outside source directory? If git didn't support this,
>> so what?
>
> lots of serious tools support it, as it this comes automatically
> when using automake. Eg. emacs, gcc, make, pango, lilypond, etc etc.
>
> It's a quite standard feature ; you should be asking why git
> shouldn't support it.
Because git is not autotool'ed project. And people protested vehemently
against adding yet another dependency. So from the whole autotools suite
only autoconf is used, and only to generate config.mak.autogen Makefile
configuration, which otherwise would be needed to be generated by hand.
BTW git tries to guess configuration based on uname -a result.
There was also for a little while hand-generated configure script, but
it got abandoned when it appeared that it is hard to be portable (and
autoconf did the work; perhaps too hard but did, not using features
which weren't common but now are in standard, but did), and the fact
that it was possible to have _optional_ autoconf support.
Add to that the fact that people said that ./configure on Cygwin is slow
(can be slow), so they prefer _not_ to run this.
Besides, the fact that some tools suport some feature is not the reason
to add it. You have to look at how often is this feature _used_. For
example you don't need it (you need only DESTDIR support) for creating
RPMS from sources.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Florian Weimer @ 2006-12-06 17:01 UTC (permalink / raw)
To: git
In-Reply-To: <20061204090549.GB30316@hand.yhbt.net>
* Eric Wong:
> Florian Weimer <fw@deneb.enyo.de> wrote:
>> * Eric Wong:
>>
>> > Does the following patch help?
>>
>> Don't think so. The issue is not timing-related. I've seen a failure
>> every 1000 requests, which suggests to me that it's hitting the
>> MaxKeepAliveRequests limit configured on the server.
>
> Actually, that's exactly what this patch should fix. git-svn restarts a
> child every 1000 revisions to avoid memory usage from going through the
> roof.
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Josef Weidendorfer @ 2006-12-06 17:00 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612061207.23437.andyparkins@gmail.com>
On Wednesday 06 December 2006 13:07, Andy Parkins wrote:
> The [branch "master"] section is such that there is no change to the
> functionality of git-pull, but that functionality is now explicitly
> documented.
Nice.
However, changing "git-clone" for this is an adhoc solution and
looks wrong.
Branching off a local development branch for a tracking branch is
the job of git-branch. So first, git-branch should be called from
git-clone to do this setup.
And git-branch should be told to change the configuration of default
behavior of git-pull, whenever it sees that you are branching off
from a branch tracking a remote one. I even would go so far to setup
a default "git-pull" action even for branching off from local branches,
by setting "branch.<newbranch>.remote = ." to merge from local "upstream".
Similar, "git-checkout -b <newbranch>" should call "git-branch"
for branch creation, too.
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Jakub Narebski @ 2006-12-06 16:58 UTC (permalink / raw)
To: git
In-Reply-To: <1165422865.29714.13.camel@ibook.zvpunry.de>
Michael Loeffler wrote:
> Am Montag, den 04.12.2006, 20:48 +0100 schrieb Jakub Narebski:
> ...
>> I'm not sure if regexp support is truly better than the usual path globbing,
>> as in fnmatch / glob.
>
> The current code does not do a real glob, this was the reason for me to
> think about regex support, I thought it is easy to use sed for this. Now
> I know it better.
We could use perl for that, but embedded perl is a bit horrible.
> I want it a bit portable, but sed on other systems (like macos or
> solaris) does not support extended REs, and the basic REs do not support
> the | operator (but this works on systems with glibc with \|).
>
> Maybe we should support something like this:
> Pull: refs/heads/v*:refs/remotes/origin/
>
> I still don't like the * on the destination ref, it looks a bit strange
> (like cp Downloads/*.mp3 Music/*).
'*' in destination part would mean $n / \n (n-th match for *).
And you need some way to mark if it is prefix match, or whole path match.
Ending prefix match with '/' is one way of doing this... Unless it would
be prefix match always, but I think this leads way to confusion.
Just a thought.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 16:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612061752.39443.jnareb@gmail.com>
Jakub Narebski escreveu:
> I'm still not sure if this has place in git. Is it really common to
> support building outside source directory? If git didn't support this,
> so what?
lots of serious tools support it, as it this comes automatically
when using automake. Eg. emacs, gcc, make, pango, lilypond, etc etc.
It's a quite standard feature ; you should be asking why git
shouldn't support it.
Another option is to make a special solution based on makefiles, so
make is run inside the srcdir, but output shunted output to a
separate objects/ subdirectory. However, it's more work, and less
standardized.
--
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 16:52 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576F29B.6010105@xs4all.nl>
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>>> there should be Makefiles in said directories. Otherwise, every rule
>>> in the toplevel Makefile saying
>>>
>>>
>>> $(MAKE) -C subdir/
>>>
>>> will fail because $builddir/ does not have a Makefile in
>>> $builddir/subdir.
>>
>> Wouldn't it be better just to modify toplevel Makefile to say:
>>
>> $(MAKE) -C $(srcdir)/subdir/
>>
>> without messing with ./configure script, and creating "redirect"
>> Makefiles?
>>
>
> that doesn't work.
>
> make -C foo bla
>
> just does
>
> (cd foo && make bla)
>
> If you did this, part of the object files would end up in the source dir;
> The idea of separate srcdir builds,is to keep the srcdir completely clean
> of generated files. That can't really be done without aid of a script,
> to setup the builddir. In this case that is the configure script.
Thanks for an explanation. At least some of it should be in commit
message, to explain what you want the patch to do.
I don't know autotools enough to check if autotools (autoconf) doesn't
have it's own way to do this, some autoconf macro, to not need to write
this script creating redirect Makefiles.
I'm still not sure if this has place in git. Is it really common to
support building outside source directory? If git didn't support this,
so what?
--
Jakub Narebski
^ permalink raw reply
* Re: git pull and merging.
From: Josef Weidendorfer @ 2006-12-06 16:44 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <cc723f590612060205p1fd26cd7u3c7efc723b0177de@mail.gmail.com>
On Wednesday 06 December 2006 11:05, Aneesh Kumar wrote:
> [branch "devel"]
> remote = origin
> merge = devel
>
> [....]
> Now i thought merge should be local reference. So i changed it to
> merge = remotes/origin/devel.
>
> That also didn't work.
>
> Then i tried the name of the branch should be indicated as
> "refs/heads/devel" . That also didn't work.
>
> So i guess i am missing something.
See man page of git-repo-config:
branch.<name>.merge
When in branch <name>, it tells git fetch the default
remote branch to be merged.
I assume that the "devel" branch on the remote repo you cloned from
is also "devel", more exactly "refs/heads/devel".
Now, instead of "git pull", git should default to
git pull origin refs/heads/devel:refs/remotes/origin/devel
ie. it should update the local tracking branch "refs/remotes/origin/devel"
with the remote branch "refs/heads/devel".
The tracking branch "refs/remotes/origin/devel" will be merged with current
branch afterwards.
Now looking at the documentation for branch.<name>.merge, it talks
about the remote branch, which is "refs/heads/devel" in your case, ie.
the first part of the refspec of the full "git pull" command above.
So, as you already posted (without explanation, therefore this mail),
the config should be
[branch "devel"]
remote = origin
merge = refs/heads/devel
However, "devel" alone should work here, as it can be matched with remote
"refs/heads/devel". Seems to be a bug, as branch.<name>.merge seems to only
being compared with the full canonical name in the implementation.
Josef
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 16:40 UTC (permalink / raw)
To: git; +Cc: git
In-Reply-To: <200612061727.54058.jnareb@gmail.com>
Jakub Narebski escreveu:
>> there should be Makefiles in said directories. Otherwise, every rule
>> in the toplevel Makefile saying
>>
>>
>> $(MAKE) -C subdir/
>>
>> will fail because $builddir/ does not have a Makefile in
>> $builddir/subdir.
>
> Wouldn't it be better just to modify toplevel Makefile to say:
>
> $(MAKE) -C $(srcdir)/subdir/
>
> without messing with ./configure script, and creating "redirect"
> Makefiles?
>
that doesn't work.
make -C foo bla
just does
(cd foo && make bla)
If you did this, part of the object files would end up in the source dir;
The idea of separate srcdir builds,is to keep the srcdir completely clean
of generated files. That can't really be done without aid of a script,
to setup the builddir. In this case that is the configure script.
I did forget to add a check
if "$srcdir" != "." ; then
..
fi
around the messy stuff.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH 2/3] git-fetch: do not use "*" for fetching multiple refs
From: Michael Loeffler @ 2006-12-06 16:34 UTC (permalink / raw)
To: git
In-Reply-To: <el1tud$n07$2@sea.gmane.org>
Am Montag, den 04.12.2006, 20:48 +0100 schrieb Jakub Narebski:
...
> I'm not sure if regexp support is truly better than the usual path globbing,
> as in fnmatch / glob.
The current code does not do a real glob, this was the reason for me to
think about regex support, I thought it is easy to use sed for this. Now
I know it better.
I want it a bit portable, but sed on other systems (like macos or
solaris) does not support extended REs, and the basic REs do not support
the | operator (but this works on systems with glibc with \|).
Maybe we should support something like this:
Pull: refs/heads/v*:refs/remotes/origin/
I still don't like the * on the destination ref, it looks a bit strange
(like cp Downloads/*.mp3 Music/*).
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 16:27 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576E9DF.5090709@xs4all.nl>
Dnia środa 6. grudnia 2006 17:03, Han-Wen Nienhuys napisał:
> Jakub Narebski escreveu:
>
>> The fact that I didn't understood what this part of patch is meant
>> to do should be the big hint that this commit needs some longer commit
>> message explaining purpose of such mess.
>>
>> I still don't understand what this part do (and how come it is
>> in configure.ac which should be _only_ about generating
>> config.mak.autogen Makefile configuration file and _not_ about
>> generating Makefiles). You want what sequence of commands to work?
>>
>> $ $srcdir/configure --srcdir=$srcdir
>> $ make -D $srcdir
>> $ make -D $srcdir DESTDIR=$DESTDIR install
>
> make -D doesn't exist.
Oops. I meant make -C, not make -D.
> This is about
>
> mkdir git-build
> cd git-build
> $my_git_source/configure
> make
>
> this _was_ actually documented in that one-line commit message, that
> you found to be too short.
Because it was so short (one line) while being long for one line.
Why don't you write above in commit message?
> Since git does recursive makes, among others in
>
> perl/
> Documentation/
> templates/
> contrib/
>
> there should be Makefiles in said directories. Otherwise, every rule
> in the toplevel Makefile saying
>
>
> $(MAKE) -C subdir/
>
> will fail because $builddir/ does not have a Makefile in
> $builddir/subdir.
Wouldn't it be better just to modify toplevel Makefile to say:
$(MAKE) -C $(srcdir)/subdir/
without messing with ./configure script, and creating "redirect"
Makefiles?
> The part you don't understand is a generic way of duplicating the
> Makefiles from the git sources, while making sure that they work when
> $srcdir != $builddir
>
>
> Yes, if builddir != srcdir , then configure is about more than
> generating config.mak.autogen
Once again: git is not autotool'ed project. Everything you want to
do should work regardless if you would run ./configure, or if you
would hand-craft config.mak file.
--
Jakub Narebski
^ permalink raw reply
* Re: git UI nit
From: Jakub Narebski @ 2006-12-06 16:23 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576EA02.2010809@xs4all.nl>
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>> Johannes Schindelin wrote:
>>
>>> On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
>>>
>>>> Johannes Schindelin escreveu:
>>>>> }
>>>>> if (quiet)
>>>>> continue;
>>>>> - printf("%s: needs update\n", ce->name);
>>>>> + printf("%s: dirty; needs commit\n", ce->name);
>>>> Yes - I'd just mention revert as an option too.
>>> Actually, I like it that short.
>>
>> So why not simply use "%s: dirty\n"?
>
> because a newbie doesn't know how to resolve that problem.
But there are [at least] two ways to resolve this:
commit or revert (reset).
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] Two conceptually distinct commit commands
From: Carl Worth @ 2006-12-06 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <874ps91v79.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]
On Tue, 05 Dec 2006 20:53:30 -0800, Carl Worth wrote:
> On Tue, 05 Dec 2006 17:13:20 -0800, Junio C Hamano wrote:
> 2. Avoiding a change of semantics triggered by merely applying
> pathname arguments without any command-line option or
> alternate command name.
By the way, the original command-line convention I used in the
proposal was that the omission of an optional argument should be
equivalent to supplying some default argument. Here's another
convention that is also useful to examine:
Adding path-name arguments limits the behavior of the command,
(and does not otherwise change the semantics).
I don't know that this is as universal a convention outside of git,
but it's quite strong within git. The path name limiting exists in
deep parts of the machinery and allows for things like:
git log -- paths... # path-limited version of "git log"
git diff -- paths... # path-limited version of "git diff"
etc.
It's interesting to look at how the various commit commands fit (or
do not fit) this convention:
git commit paths...
git commit --only paths...
This command cannot be explained in terms of the semantics of
"git commit" (without command-line options). This command
_can_ be explained as a path-limited version of "git commit -a".
git commit --include paths...
This command does something _extra_ to the given paths before
executing the equivalent of "git commit". I think this is a
fairly unique violation of the path-limiting convention.
The proposal I made with commit-working-tree-content and
commit-index-content consistently follow the path-limiting convention.
I think consistency of command-line conventions like this are
important for making the tool usable. And there have been notable
improvements to consistency of convention in git recently, (for
example, using <since>..[<until>] in git-format-patch rather than
<his> <mine>).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git UI nit
From: Han-Wen Nienhuys @ 2006-12-06 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <el6nul$58n$2@sea.gmane.org>
Jakub Narebski escreveu:
> Johannes Schindelin wrote:
>
>> On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
>>
>>> Johannes Schindelin escreveu:
>>>> }
>>>> if (quiet)
>>>> continue;
>>>> - printf("%s: needs update\n", ce->name);
>>>> + printf("%s: dirty; needs commit\n", ce->name);
>>> Yes - I'd just mention revert as an option too.
>> Actually, I like it that short.
>
> So why not simply use "%s: dirty\n"?
because a newbie doesn't know how to resolve that problem.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 16:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612061656.55888.jnareb@gmail.com>
Jakub Narebski escreveu:
> The fact that I didn't understood what this part of patch is meant
> to do should be the big hint that this commit needs some longer commit
> message explaining purpose of such mess.
>
> I still don't understand what this part do (and how come it is
> in configure.ac which should be _only_ about generating
> config.mak.autogen Makefile configuration file and _not_ about
> generating Makefiles). You want what sequence of commands to work?
>
> $ $srcdir/configure --srcdir=$srcdir
> $ make -D $srcdir
> $ make -D $srcdir DESTDIR=$DESTDIR install
make -D doesn't exist.
This is about
mkdir git-build
cd git-build
$my_git_source/configure
make
this _was_ actually documented in that one-line commit message, that
you found to be too short.
Since git does recursive makes, among others in
perl/
Documentation/
templates/
contrib/
there should be Makefiles in said directories. Otherwise, every rule
in the toplevel Makefile saying
$(MAKE) -C subdir/
will fail because $builddir/ does not have a Makefile in
$builddir/subdir.
The part you don't understand is a generic way of duplicating the
Makefiles from the git sources, while making sure that they work when
$srcdir != $builddir
Yes, if builddir != srcdir , then configure is about more than
generating config.mak.autogen
--
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 15:56 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576E38F.1020404@xs4all.nl>
Dnia środa 6. grudnia 2006 16:36, Han-Wen Nienhuys napisał:
> Jakub Narebski escreveu:
[...]
>>>>> + if test -f $srcdir/$d/Makefile ; then
> [..]
>>>>> + echo creating $d/Makefile
>>>>> + cat << EOF> $d/Makefile
>
>>>> This part IMHO has no sense, and has no place here.
>>
>> If you want to create or modify Makefiles, do that. Not generate
>> "minimal" Makefiles in every and each subdirectory.
>
> Look more closely at the patch. It only generates Makefiles in
> directories that have makefiles in the source dir. The makefiles are
> short because that is the easiest to do.
The fact that I didn't understood what this part of patch is meant
to do should be the big hint that this commit needs some longer commit
message explaining purpose of such mess.
I still don't understand what this part do (and how come it is
in configure.ac which should be _only_ about generating
config.mak.autogen Makefile configuration file and _not_ about
generating Makefiles). You want what sequence of commands to work?
$ $srcdir/configure --srcdir=$srcdir
$ make -D $srcdir
$ make -D $srcdir DESTDIR=$DESTDIR install
or what? Why this part is needed?
Once again: git is NOT autotool'ed project. And shouldn't be.
> I'm happy to amend the patch, but I can't properly test
> it until the perl problem gets sorted out.
I'll be waiting.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] merge-file: support -p and -q; fix compile warnings
From: Johannes Schindelin @ 2006-12-06 15:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el6nhv$58n$1@sea.gmane.org>
Now merge-file also understands --stdout and --quiet options. While
at it, two compile warnings were fixed.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Wed, 6 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > merge-file has the same syntax as RCS merge, but supports only
> > the "-L" option.
>
> Would it be hard to add "-p / --stdout" options, and "-q /
> --quiet" option?
No.
But the documentation has to be done by somebody else.
builtin-merge-file.c | 29 ++++++++++++++++++-----------
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 11976ea..9ae1009 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -2,7 +2,7 @@
#include "xdiff/xdiff.h"
static const char merge_file_usage[] =
-"git merge-file [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+"git merge-file [-p | --stdout] [-q | --quiet] [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
static int read_file(mmfile_t *ptr, const char *filename)
{
@@ -24,18 +24,25 @@ static int read_file(mmfile_t *ptr, const char *filename)
int cmd_merge_file(int argc, char **argv, char **envp)
{
char *names[3];
- char *buffers[3];
- mmfile_t mmfs[3], result = {NULL, 0};
- int ret = 0, i = 0;
+ mmfile_t mmfs[3];
+ mmbuffer_t result = {NULL, 0};
+ int ret = 0, i = 0, to_stdout = 0;
while (argc > 4) {
- if (!strcmp(argv[1], "-L")) {
+ if (!strcmp(argv[1], "-L") && i < 3) {
names[i++] = argv[2];
- argc -= 2;
- argv += 2;
- continue;
- }
- usage(merge_file_usage);
+ argc--;
+ argv++;
+ } else if (!strcmp(argv[1], "-p") ||
+ !strcmp(argv[1], "--stdout"))
+ to_stdout = 1;
+ else if (!strcmp(argv[1], "-q") ||
+ !strcmp(argv[1], "--quiet"))
+ freopen("/dev/null", "w", stderr);
+ else
+ usage(merge_file_usage);
+ argc--;
+ argv++;
}
if (argc != 4)
@@ -57,7 +64,7 @@ int cmd_merge_file(int argc, char **argv, char **envp)
if (ret >= 0) {
char *filename = argv[1];
- FILE *f = fopen(filename, "wb");
+ FILE *f = to_stdout ? stdout : fopen(filename, "wb");
if (!f)
ret = error("Could not open %s for writing", filename);
--
^ permalink raw reply related
* Re: git UI nit
From: Han-Wen Nienhuys @ 2006-12-06 15:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612061619120.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> Actually, I like it that short.
>
> We had an email on this list, where the poster said he could not merge
> with Git. It turned out that the merge failed with conflicts, but he
> did not bother reading through the messages, apparently because they were
> too many.
good point.
--
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 15:36 UTC (permalink / raw)
To: git
In-Reply-To: <200612061627.40359.jnareb@gmail.com>
Jakub Narebski escreveu:
> Still I think that at least
>
> datarootdir = @datarootdir@
>
> should be not removed.
yes, agreed.
>>>> + if test -f $srcdir/$d/Makefile ; then
[..]
>>>> + echo creating $d/Makefile
>>>> + cat << EOF> $d/Makefile
>>> This part IMHO has no sense, and has no place here.
>
> If you want to create or modify Makefiles, do that. Not generate
> "minimal" Makefiles in every and each subdirectory.
Look more closely at the patch. It only generates Makefiles in
directories that have makefiles in the source dir. The makefiles are
short because that is the easiest to do.
I'm happy to amend the patch, bUt I can't properly test
it until the perl problem gets sorted out.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: git UI nit
From: Jakub Narebski @ 2006-12-06 15:36 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612061619120.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
>
>> Johannes Schindelin escreveu:
>>> }
>>> if (quiet)
>>> continue;
>>> - printf("%s: needs update\n", ce->name);
>>> + printf("%s: dirty; needs commit\n", ce->name);
>>
>> Yes - I'd just mention revert as an option too.
>
> Actually, I like it that short.
So why not simply use "%s: dirty\n"?
> We had an email on this list, where the poster said he could not merge
> with Git. It turned out that the merge failed with conflicts, but he
> did not bother reading through the messages, apparently because they were
> too many.
Some of that stems from the "pipeline" model / implementation of git
commands, where every separate stage spews it's own warning and error
messages.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Add builtin merge-file, a minimal replacement for RCS merge
From: Jakub Narebski @ 2006-12-06 15:30 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612061609430.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> merge-file has the same syntax as RCS merge, but supports only the
> "-L" option.
Would it be hard to add "-p / --stdout" options, and "-q / --quiet" option?
I understand that non-standard output format options are rather out of
question...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 15:27 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576DBA5.4080002@xs4all.nl>
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>
>> Please add some longer commit message.
>
> do you have any specifics you would like me to mention?
More detailed description what "Allow non-srcdir builds using cd
$builddir && $srcdir/configure" mean and why we might want to do that.
For example:
We might want to build git from outside source directory. For this we
need...
By the way, I think this patch is about _two_ changes. Allow to build
outside source directory, by providing srcdir AND separate change to
allow builds of separate parts of git, with separate Makefile, to
include user-generated configuration file config.mak and ./configure
generated config.mak.autogen configuration file.
Shouldn't this patch be split into two?
>>> exec_prefix = @exec_prefix@
>>> bindir = @bindir@
>>> -#gitexecdir = @libexecdir@/git-core/
>>> -datarootdir = @datarootdir@
>>> -template_dir = @datadir@/git-core/templates/
>>>
>>> mandir=@mandir@
>>
>> Why have you removed setting datarootdir and template_dir? I would
>> have thought that you would rather change it to
>>
>> #gitexecdir = @libexecdir@/git-core/
>> datarootdir = @datarootdir@
>> GIT_datadir = @datadir@/git-core/
>> template_dir= @datadir@/git-core/templates/
>
> The Makefile already has this code, so adding it here is duplication
> of work and code.
Good call. Well, at least now, when ./configure script doesn't provide
means to change template_dir etc. from command line, via options.
Still I think that at least
datarootdir = @datarootdir@
should be not removed.
> If you think putting code in the generated file is a good idea, I
> propose we just generate the entire Makefile, as is the standard usage
> for autoconf.
The stance on autoconf is that it has to be _optional_ part of
compilation. And I think it does good job of this.
>>> +## generate subdirectories and sub Makefiles.
>>> +for d in `cd $srcdir && find . -type d -print | grep -v '\.git'` ;
>>> +do
>>> + if test ! -d $d ; then
>>> + echo creating $d
>>> + mkdir $d
>>> + fi
>>> +
>>> + if test -f $srcdir/$d/Makefile ; then
>>> +
>>> + dnl [[]] is to keep m4 happy
>>> + depth=`echo $d/ | sed -e 's!^\./!!g' -e 's![[^/]]*/!../!g'`
>>> + echo creating $d/Makefile
>>> + cat << EOF> $d/Makefile
>>> +include ${depth}config.mak.autogen
>>> +here-srcdir=\$(srcdir)/$d/
>>> +VPATH=\$(here-srcdir)
>>> +include \$(here-srcdir)/Makefile
>>> +EOF
>>> +
>>> + fi
>>> +done
>>> +exit 1
>>
>> What is this for? The ./configure script, generated by autoconf from
>> configure.ac (by "make configure"), generates config.mak.autogen file
>> from config.mak.in, which is included in main (top) Makefile.
>
> in some cases, the files can also be called stand alone, eg.
>
> [lilydev@haring perl]$ pwd
> /home/lilydev/vc/git/perl
>
> [lilydev@haring perl]$ make
> make -f perl.mak all
> make[1]: Entering directory `/home/lilydev/vc/git/perl'
> make[1]: Leaving directory `/home/lilydev/vc/git/perl'
>
> The above Makefile generation makes sure that this behavior is
> mirrored in the builddir. Also, I'm not sure if the vpath settings get
> exported automatically.
>
> Having multiple Makefiles in the builddir is the standard behavior for
> autotool'ed packages.
Git is not autotool'ed package. Autoconf is used only for _optional_
compile and installation configuration.
>> The variables defined in config.mak.autogen are of course visible in
>> make in subdirectories (make invoked from main makefile). Why the
>> change? What about user-generated config.mak?
>
> good point. I'll include it too.
>
>> This part IMHO has no sense, and has no place here.
If you want to create or modify Makefiles, do that. Not generate
"minimal" Makefiles in every and each subdirectory.
You would be able to compile git fully only from top directory. So what?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Add builtin merge-file, a minimal replacement for RCS merge
From: Johannes Schindelin @ 2006-12-06 15:26 UTC (permalink / raw)
To: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612061609430.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Oops. Here is a corrected patch:
Makefile | 1
builtin-merge-file.c | 72 ++++++++++++++++++++++++++++++
builtin.h | 1
git.c | 1
t/t6023-merge-file.sh | 116 +++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 191 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index cf69242..81cc7c4 100644
--- a/Makefile
+++ b/Makefile
@@ -275,6 +283,7 @@ BUILTIN_OBJS = \
builtin-ls-tree.o \
builtin-mailinfo.o \
builtin-mailsplit.o \
+ builtin-merge-file.o \
builtin-mv.o \
builtin-name-rev.o \
builtin-pack-objects.o \
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
new file mode 100644
index 0000000..11976ea
--- /dev/null
+++ b/builtin-merge-file.c
@@ -0,0 +1,72 @@
+#include "cache.h"
+#include "xdiff/xdiff.h"
+
+static const char merge_file_usage[] =
+"git merge-file [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+
+static int read_file(mmfile_t *ptr, const char *filename)
+{
+ struct stat st;
+ FILE *f;
+
+ if (stat(filename, &st))
+ return error("Could not stat %s", filename);
+ if ((f = fopen(filename, "rb")) == NULL)
+ return error("Could not open %s", filename);
+ ptr->ptr = xmalloc(st.st_size);
+ if (fread(ptr->ptr, st.st_size, 1, f) != 1)
+ return error("Could not read %s", filename);
+ fclose(f);
+ ptr->size = st.st_size;
+ return 0;
+}
+
+int cmd_merge_file(int argc, char **argv, char **envp)
+{
+ char *names[3];
+ char *buffers[3];
+ mmfile_t mmfs[3], result = {NULL, 0};
+ int ret = 0, i = 0;
+
+ while (argc > 4) {
+ if (!strcmp(argv[1], "-L")) {
+ names[i++] = argv[2];
+ argc -= 2;
+ argv += 2;
+ continue;
+ }
+ usage(merge_file_usage);
+ }
+
+ if (argc != 4)
+ usage(merge_file_usage);
+
+ for (; i < 3; i++)
+ names[i] = argv[i + 1];
+
+ for (i = 0; i < 3; i++)
+ if (read_file(mmfs + i, argv[i + 1]))
+ return -1;
+
+ xpparam_t xpp = {XDF_NEED_MINIMAL};
+ ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
+ &xpp, XDL_MERGE_ZEALOUS, &result);
+
+ for (i = 0; i < 3; i++)
+ free(mmfs[i].ptr);
+
+ if (ret >= 0) {
+ char *filename = argv[1];
+ FILE *f = fopen(filename, "wb");
+
+ if (!f)
+ ret = error("Could not open %s for writing", filename);
+ else if (fwrite(result.ptr, result.size, 1, f) != 1)
+ ret = error("Could not write to %s", filename);
+ else if (fclose(f))
+ ret = error("Could not close %s", filename);
+ free(result.ptr);
+ }
+
+ return ret;
+}
diff --git a/builtin.h b/builtin.h
index b5116f3..08519e7 100644
--- a/builtin.h
+++ b/builtin.h
@@ -42,6 +42,7 @@ extern int cmd_ls_files(int argc, const char **argv, const char *prefix);
extern int cmd_ls_tree(int argc, const char **argv, const char *prefix);
extern int cmd_mailinfo(int argc, const char **argv, const char *prefix);
extern int cmd_mailsplit(int argc, const char **argv, const char *prefix);
+extern int cmd_merge_file(int argc, const char **argv, const char *prefix);
extern int cmd_mv(int argc, const char **argv, const char *prefix);
extern int cmd_name_rev(int argc, const char **argv, const char *prefix);
extern int cmd_pack_objects(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 357330e..cb5a7ef 100644
--- a/git.c
+++ b/git.c
@@ -242,6 +252,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "ls-tree", cmd_ls_tree, RUN_SETUP },
{ "mailinfo", cmd_mailinfo },
{ "mailsplit", cmd_mailsplit },
+ { "merge-file", cmd_merge_file },
{ "mv", cmd_mv, RUN_SETUP },
{ "name-rev", cmd_name_rev, RUN_SETUP },
{ "pack-objects", cmd_pack_objects, RUN_SETUP },
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
new file mode 100644
index 0000000..5d9b6f3
--- /dev/null
+++ b/t/t6023-merge-file.sh
@@ -0,0 +1,116 @@
+#!/bin/sh
+
+test_description='RCS merge replacement: merge-file'
+. ./test-lib.sh
+
+cat > orig.txt << EOF
+Dominus regit me,
+et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+EOF
+
+cat > new1.txt << EOF
+Dominus regit me,
+et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+Nam et si ambulavero in medio umbrae mortis,
+non timebo mala, quoniam tu mecum es:
+virga tua et baculus tuus ipsa me consolata sunt.
+EOF
+
+cat > new2.txt << EOF
+Dominus regit me, et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+EOF
+
+cat > new3.txt << EOF
+DOMINUS regit me,
+et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+EOF
+
+cat > new4.txt << EOF
+Dominus regit me, et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+EOF
+echo -n "propter nomen suum." >> new4.txt
+
+cp new1.txt test.txt
+test_expect_success "merge without conflict" \
+ "git-merge-file test.txt orig.txt new2.txt"
+
+cp new1.txt test2.txt
+test_expect_success "merge without conflict (missing LF at EOF)" \
+ "git-merge-file test2.txt orig.txt new2.txt"
+
+test_expect_success "merge result added missing LF" \
+ "diff -u test.txt test2.txt"
+
+cp test.txt backup.txt
+test_expect_failure "merge with conflicts" \
+ "git-merge-file test.txt orig.txt new3.txt"
+
+cat > expect.txt << EOF
+<<<<<<< test.txt
+Dominus regit me, et nihil mihi deerit.
+=======
+DOMINUS regit me,
+et nihil mihi deerit.
+>>>>>>> new3.txt
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+Nam et si ambulavero in medio umbrae mortis,
+non timebo mala, quoniam tu mecum es:
+virga tua et baculus tuus ipsa me consolata sunt.
+EOF
+
+test_expect_success "expected conflict markers" "diff -u test.txt expect.txt"
+
+cp backup.txt test.txt
+test_expect_failure "merge with conflicts, using -L" \
+ "git-merge-file -L 1 -L 2 test.txt orig.txt new3.txt"
+
+cat > expect.txt << EOF
+<<<<<<< 1
+Dominus regit me, et nihil mihi deerit.
+=======
+DOMINUS regit me,
+et nihil mihi deerit.
+>>>>>>> new3.txt
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+Nam et si ambulavero in medio umbrae mortis,
+non timebo mala, quoniam tu mecum es:
+virga tua et baculus tuus ipsa me consolata sunt.
+EOF
+
+test_expect_success "expected conflict markers, with -L" \
+ "diff -u test.txt expect.txt"
+
+test_done
+
^ permalink raw reply related
* Re: git UI nit
From: Johannes Schindelin @ 2006-12-06 15:20 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576DD27.6050307@xs4all.nl>
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> > }
> > if (quiet)
> > continue;
> > - printf("%s: needs update\n", ce->name);
> > + printf("%s: dirty; needs commit\n", ce->name);
>
> Yes - I'd just mention revert as an option too.
Actually, I like it that short.
We had an email on this list, where the poster said he could not merge
with Git. It turned out that the merge failed with conflicts, but he
did not bother reading through the messages, apparently because they were
too many.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Johannes Schindelin @ 2006-12-06 15:16 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Han-Wen Nienhuys, gpermus, hanwen, git
In-Reply-To: <20061206145802.GC1714@fieldses.org>
Hi,
On Wed, 6 Dec 2006, J. Bruce Fields wrote:
> I'd rather leave that introduction as it is--just as a section that
> advertises the git features without trying to explain much. And I'd
> rather not mention push until we have a chance to explain how to use it.
You talk like you'd have an eternity to explain Git. But that is not true.
A developer, especially those whom Git is forced upon, have an attention
span shorter than their pub1c hair.
I _know_ that _I_ did not read the whole document about "Branching and
merging in Git".
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add builtin merge-file, a minimal replacement for RCS merge
From: Johannes Schindelin @ 2006-12-06 15:10 UTC (permalink / raw)
To: git, junkio
merge-file has the same syntax as RCS merge, but supports only the
"-L" option.
For good measure, a test is added, which is quite minimal, though.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Is it a good sign that the test makes up for 75% of this patch?
builtin-merge-file.c | 72 ++++++++++++++
builtin.h | 1 +
git.c | 1 +
t/t6023-merge-file.sh | 251 ++++++++++++++++---------------------------------
4 files changed, 157 insertions(+), 168 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
new file mode 100644
index 0000000..11976ea
--- /dev/null
+++ b/builtin-merge-file.c
@@ -0,0 +1,72 @@
+#include "cache.h"
+#include "xdiff/xdiff.h"
+
+static const char merge_file_usage[] =
+"git merge-file [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+
+static int read_file(mmfile_t *ptr, const char *filename)
+{
+ struct stat st;
+ FILE *f;
+
+ if (stat(filename, &st))
+ return error("Could not stat %s", filename);
+ if ((f = fopen(filename, "rb")) == NULL)
+ return error("Could not open %s", filename);
+ ptr->ptr = xmalloc(st.st_size);
+ if (fread(ptr->ptr, st.st_size, 1, f) != 1)
+ return error("Could not read %s", filename);
+ fclose(f);
+ ptr->size = st.st_size;
+ return 0;
+}
+
+int cmd_merge_file(int argc, char **argv, char **envp)
+{
+ char *names[3];
+ char *buffers[3];
+ mmfile_t mmfs[3], result = {NULL, 0};
+ int ret = 0, i = 0;
+
+ while (argc > 4) {
+ if (!strcmp(argv[1], "-L")) {
+ names[i++] = argv[2];
+ argc -= 2;
+ argv += 2;
+ continue;
+ }
+ usage(merge_file_usage);
+ }
+
+ if (argc != 4)
+ usage(merge_file_usage);
+
+ for (; i < 3; i++)
+ names[i] = argv[i + 1];
+
+ for (i = 0; i < 3; i++)
+ if (read_file(mmfs + i, argv[i + 1]))
+ return -1;
+
+ xpparam_t xpp = {XDF_NEED_MINIMAL};
+ ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
+ &xpp, XDL_MERGE_ZEALOUS, &result);
+
+ for (i = 0; i < 3; i++)
+ free(mmfs[i].ptr);
+
+ if (ret >= 0) {
+ char *filename = argv[1];
+ FILE *f = fopen(filename, "wb");
+
+ if (!f)
+ ret = error("Could not open %s for writing", filename);
+ else if (fwrite(result.ptr, result.size, 1, f) != 1)
+ ret = error("Could not write to %s", filename);
+ else if (fclose(f))
+ ret = error("Could not close %s", filename);
+ free(result.ptr);
+ }
+
+ return ret;
+}
diff --git a/builtin.h b/builtin.h
index b5116f3..08519e7 100644
--- a/builtin.h
+++ b/builtin.h
@@ -42,6 +42,7 @@ extern int cmd_ls_files(int argc, const char **argv, const char *prefix);
extern int cmd_ls_tree(int argc, const char **argv, const char *prefix);
extern int cmd_mailinfo(int argc, const char **argv, const char *prefix);
extern int cmd_mailsplit(int argc, const char **argv, const char *prefix);
+extern int cmd_merge_file(int argc, const char **argv, const char *prefix);
extern int cmd_mv(int argc, const char **argv, const char *prefix);
extern int cmd_name_rev(int argc, const char **argv, const char *prefix);
extern int cmd_pack_objects(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 63a4747..cb5a7ef 100644
--- a/git.c
+++ b/git.c
@@ -252,6 +252,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "ls-tree", cmd_ls_tree, RUN_SETUP },
{ "mailinfo", cmd_mailinfo },
{ "mailsplit", cmd_mailsplit },
+ { "merge-file", cmd_merge_file },
{ "mv", cmd_mv, RUN_SETUP },
{ "name-rev", cmd_name_rev, RUN_SETUP },
{ "pack-objects", cmd_pack_objects, RUN_SETUP },
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index 53246f2..5d9b6f3 100644
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -11,191 +11,106 @@ super aquam refectionis educavit me;
animam meam convertit,
deduxit me super semitas jusitiae,
propter nomen suum.
+EOF
+
+cat > new1.txt << EOF
+Dominus regit me,
+et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
Nam et si ambulavero in medio umbrae mortis,
non timebo mala, quoniam tu mecum es:
virga tua et baculus tuus ipsa me consolata sunt.
-Parasti in conspectu meo mensam,
-adversus eos qui tribulant me;
-impinguasti in oleo caput meum,
-et calix meus inebrians quam praeclarus est!
-Et misericordia tua subsequetur me omnibus diebus vitae meae,
-et ut inhabitem in domo Domini in longitudinem dierum.
EOF
-cp orig.txt with-empty-lines.txt
-git apply --unidiff-zero << EOF
---- with-empty-lines.txt
-+++ with-empty-lines.txt
-@@ -3,0 +3 @@
-+
-@@ -5,0 +6 @@
-+
-@@ -8,0 +10 @@
-+
-@@ -11,0 +14 @@
-+
-@@ -15,0 +19 @@
-+
-@@ -17,0 +22 @@
-+
+cat > new2.txt << EOF
+Dominus regit me, et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
EOF
-(cat orig.txt; echo; echo "Psalmus David") > with-reference.txt
-
-cp orig.txt different-capitalisation.txt
-git apply --unidiff-zero << EOF
---- different-capitalisation.txt
-+++ different-capitalisation.txt
-@@ -3,2 +3,2 @@
--In loco pascuae ibi me collocavit,
--super aquam refectionis educavit me;
-+in loco pascuae ibi me collocavit.
-+Super aquam refectionis educavit me;
-@@ -6 +6 @@
--deduxit me super semitas jusitiae,
-+Deduxit me super semitas jusitiae,
-@@ -10 +10 @@
--virga tua et baculus tuus ipsa me consolata sunt.
-+Virga tua et baculus tuus ipsa me consolata sunt.
-@@ -13 +13 @@
--impinguasti in oleo caput meum,
-+Impinguasti in oleo caput meum,
-@@ -16 +16 @@
--et ut inhabitem in domo Domini in longitudinem dierum.
-+Et ut inhabitem in domo Domini in longitudinem dierum.
+cat > new3.txt << EOF
+DOMINUS regit me,
+et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
EOF
-cp orig.txt with-numbers.txt
-git apply --unidiff-zero << EOF
---- with-numbers.txt
-+++ with-numbers.txt
-@@ -1 +1 @@
--Dominus regit me,
-+1. Dominus regit me,
-@@ -3 +3 @@
--In loco pascuae ibi me collocavit,
-+2. In loco pascuae ibi me collocavit,
-@@ -5 +5 @@
--animam meam convertit,
-+3. animam meam convertit,
-@@ -8 +8 @@
--Nam et si ambulavero in medio umbrae mortis,
-+4. Nam et si ambulavero in medio umbrae mortis,
-@@ -11 +11 @@
--Parasti in conspectu meo mensam,
-+5. Parasti in conspectu meo mensam,
-@@ -15 +15 @@
--Et misericordia tua subsequetur me omnibus diebus vitae meae,
-+6. Et misericordia tua subsequetur me omnibus diebus vitae meae,
+cat > new4.txt << EOF
+Dominus regit me, et nihil mihi deerit.
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
EOF
+echo -n "propter nomen suum." >> new4.txt
-# Excusez-moi, je n'ai clavier avec des accents...
-
-cp orig.txt avec-francais.txt
-git apply --unidiff-zero << EOF
---- avec-francais.txt
-+++ avec-francais.txt
-@@ -3,0 +3,3 @@
-+
-+Le Seigneur est mon berger,
-+je ne manquerai de rien.
-@@ -5,0 +8,3 @@
-+
-+Il me met au repos dans des pres d'herbe fraiche,
-+il me conduit au calme pres de l'eau.
-@@ -8,0 +14,4 @@
-+
-+Il ranime mes forces,
-+il me guide sur la bonne voie,
-+parce qu'il est le berger d'Israel.
-@@ -11,0 +21,4 @@
-+
-+Meme si je passe par la vallee obscure,
-+je ne redoute aucun mal, Seigneur, car tu m'accompagnes.
-+Tu me conduis, tu me defends, voila ce qui me rassure.
-@@ -15,0 +29,5 @@
-+
-+Face a ceux qui me veulent du mal,
-+tu prepares un banquet pour moi.
-+Tu m'accueilles en versant sur ma teete un peu d'huile parfumee.
-+Tu remplis ma coupe jusqu'au bord.
-@@ -17,0 +35,5 @@
-+
-+Oui, tous les jours de ma vie,
-+ta bonte, ta generosite me suivront pas a pas.
-+Seigneur, je reviendrai dans ta maison
-+aussi longtemps que je vivrai.
-EOF
+cp new1.txt test.txt
+test_expect_success "merge without conflict" \
+ "git-merge-file test.txt orig.txt new2.txt"
-cp with-numbers.txt with-empty-lines-and-numbers-conflict.txt
-git apply --unidiff-zero << EOF
---- with-empty-lines-and-numbers-conflict.txt
-+++ with-empty-lines-and-numbers-conflict.txt
-@@ -2,0 +3,4 @@
-+<<<<<<< new.txt
-+
-+In loco pascuae ibi me collocavit,
-+=======
-@@ -3,0 +8 @@
-+>>>>>>> with-numbers.txt
-@@ -4,0 +10,4 @@
-+<<<<<<< new.txt
-+
-+animam meam convertit,
-+=======
-@@ -5,0 +15 @@
-+>>>>>>> with-numbers.txt
-@@ -7,0 +18,4 @@
-+<<<<<<< new.txt
-+
-+Nam et si ambulavero in medio umbrae mortis,
-+=======
-@@ -8,0 +23 @@
-+>>>>>>> with-numbers.txt
-@@ -10,0 +26,4 @@
-+<<<<<<< new.txt
-+
-+Parasti in conspectu meo mensam,
-+=======
-@@ -11,0 +31 @@
-+>>>>>>> with-numbers.txt
-@@ -14,0 +35,4 @@
-+<<<<<<< new.txt
-+
-+Et misericordia tua subsequetur me omnibus diebus vitae meae,
-+=======
-@@ -15,0 +40 @@
-+>>>>>>> with-numbers.txt
-@@ -16,0 +42 @@
-+
-EOF
+cp new1.txt test2.txt
+test_expect_success "merge without conflict (missing LF at EOF)" \
+ "git-merge-file test2.txt orig.txt new2.txt"
+
+test_expect_success "merge result added missing LF" \
+ "diff -u test.txt test2.txt"
-cp with-numbers.txt with-empty-lines-and-numbers.txt
-git apply --unidiff-zero << EOF
---- with-empty-lines-and-numbers.txt
-+++ with-empty-lines-and-numbers.txt
-@@ -2,0 +3 @@
-+
-@@ -4,0 +6 @@
-+
-@@ -7,0 +10 @@
-+
-@@ -10,0 +14 @@
-+
-@@ -14,0 +19 @@
-+
+cp test.txt backup.txt
+test_expect_failure "merge with conflicts" \
+ "git-merge-file test.txt orig.txt new3.txt"
+
+cat > expect.txt << EOF
+<<<<<<< test.txt
+Dominus regit me, et nihil mihi deerit.
+=======
+DOMINUS regit me,
+et nihil mihi deerit.
+>>>>>>> new3.txt
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+Nam et si ambulavero in medio umbrae mortis,
+non timebo mala, quoniam tu mecum es:
+virga tua et baculus tuus ipsa me consolata sunt.
EOF
-cp with-empty-lines.txt new.txt
-test_expect_failure "merge empty-lines and numbers" \
- "git-merge-file new.txt orig.txt with-numbers.txt"
+test_expect_success "expected conflict markers" "diff -u test.txt expect.txt"
+
+cp backup.txt test.txt
+test_expect_failure "merge with conflicts, using -L" \
+ "git-merge-file -L 1 -L 2 test.txt orig.txt new3.txt"
-test_expect_success "conflict markers of failed merge" \
- "diff -u new.txt with-empty-lines-and-numbers-conflict.txt"
+cat > expect.txt << EOF
+<<<<<<< 1
+Dominus regit me, et nihil mihi deerit.
+=======
+DOMINUS regit me,
+et nihil mihi deerit.
+>>>>>>> new3.txt
+In loco pascuae ibi me collocavit,
+super aquam refectionis educavit me;
+animam meam convertit,
+deduxit me super semitas jusitiae,
+propter nomen suum.
+Nam et si ambulavero in medio umbrae mortis,
+non timebo mala, quoniam tu mecum es:
+virga tua et baculus tuus ipsa me consolata sunt.
+EOF
-cp with-empty-lines-and-numbers.txt new.txt
-test_expect_success "merge with title" \
- "git-merge-file new.txt orig.txt with-reference.txt"
+test_expect_success "expected conflict markers, with -L" \
+ "diff -u test.txt expect.txt"
test_done
--
1.4.4.1.g064f-dirty
^ 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