* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Jakub Narebski @ 2006-12-06 12:32 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612061325320.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> + * Since every working tree contains a repository, a commit will not
> + publish your changes; it will only create a revision. You have to
> + "push" your changes to a public repository to make them visible
> + to others.
> +
I'm not sure about context of this addition, but it is simply not
true if you publish your working repository. Granted, usually one
sets up bare public publishing repository...
By publish I mean set up http(s):// or git://, or ssh+git://, or local
transport.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Peter Baumann @ 2006-12-06 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <200612061207.23437.andyparkins@gmail.com>
On 2006-12-06, Andy Parkins <andyparkins@gmail.com> wrote:
> Without any specification in the .git/config file, git-pull will execute
> "git-pull origin"; which in turn defaults to pull from the first "pull"
> definition for the remote, "origin".
>
> This is a difficult set of defaults to track for a new user, and it's
> difficult to see what tells git to do this (especially when it is
> actually hard-coded behaviour). To ameliorate this slightly, this patch
> explicitly specifies the default behaviour during a clone using the
> "branch" section of the config.
>
> For example, a clone of a typical repository would create a .git/config
> containing:
> [remote "origin"]
> url = proto://host/repo.git
> fetch = refs/heads/master:refs/remotes/origin/master
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> The [branch "master"] section is such that there is no change to the
> functionality of git-pull, but that functionality is now explicitly
> documented.
>
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> This is really to help newbies. By explicitly documenting the default
> behaviour, it makes it clearer what is going on. It also means no routing
> through documentation to find out what config option needs changing.
>
I second that. It took me a while to understand why the first entry in
remotes/origin merged with the current branch. I thought it was a bug
because sometimes it did the right thing and once in a while nothing
went wrong.
Obviously, it have switched the branch. I even tried to made this
"buggy" behaviour reproducable to write a bugreport, but after several
days the light goes on and I just felt a little bit stupid :-)
> It's possible that we would want to remove the default behaviour entirely
> if there is no "branch" definition in the config. That would prevent
> accidents by users who don't know what pull does fully yet.
>
I'm not absolutly sure about this, but with --use-separate-remote this makes
sense, because you can easly teach someone new to git that the changes
from the remote branches are under refs/remotes/<branches> and (s)he
could merge it with git-pull . refs/remotes/$branch
No more clueless users why git pull on master branch updated the working
tree and git pull an other branch does nothing.
-Peter
> git-clone.sh | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/git-clone.sh b/git-clone.sh
> index 826fdda..992cb7c 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -413,7 +413,9 @@ then
> rm -f "refs/remotes/$origin/HEAD"
> git-symbolic-ref "refs/remotes/$origin/HEAD" \
> "refs/remotes/$origin/$head_points_at"
> - esac
> + esac &&
> + git-repo-config branch."$head_points_at".remote "$origin" &&
> + git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
> esac
>
> case "$no_checkout" in
^ permalink raw reply
* unmark after committing with git.el
From: Han-Wen Nienhuys @ 2006-12-06 12:43 UTC (permalink / raw)
To: git; +Cc: Alexandre Julliard
Hi,
in the usual workflow, I mark a few files, and then commit, and then
mark another few for commit.
This patch removes the need to unmark between commits.
From ad694b33e033e3638043cd2d2970e6248beecb91 Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Wed, 6 Dec 2006 13:41:09 +0100
Subject: [PATCH] git.el: unmark files in after committing.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 972c402..642f7bb 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -596,7 +596,8 @@ and returns the process output as a string."
(git-run-command nil nil "rerere"))
(git-refresh-files)
(git-refresh-ewoc-hf git-status)
- (message "Committed %s." commit))
+ (message "Committed %s." commit)
+ (git-unmark-all))
(message "Commit aborted."))))
(message "No files to commit.")))
(delete-file index-file))))))
--
1.4.4.1.gc9922-dirty
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: [RFC] gitweb: Add committags support (take 2)
From: Jakub Narebski @ 2006-12-06 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz64ortu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I have thought about putting %committags and @committags before
>> loading config file
>> do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
>> which can load config file depending on the project, but perhaps
>> it is too complicated solution.
>
> I think you are talking about a gitweb-instance wide
> customization, but that's not what I meant. I meant per-project
> configuration where w/git-gui.git and w/git.git are served by
> the same instance of gitweb but have pointers to different issue
> trackers.
It looks like the hardest part with committags support wouldn't be the
actual implementation of it, but coming with easy and fast way to set
up those committags.
gitweb-xmms2 project from which the idea of committags support in gitweb
came (I think, correct me if I'm wrong) avoids this issue by having
issue tracker / bug tracker the same for all projects served by single
gitweb installation; the configuration is site-wide, and there is no
per project committags configuration.
I have imagined the following twofold solution.
1. Make it easier to have per repository gitweb configuration, for
example by having gitweb configuration file in GIT_DIR for a project,
"gitweb_conf.perl" by default:
our $GITWEB_REPO_CONFIG = $ENV{'GITWEB_REPO_CONFIG'} ||
"++GITWEB_CONFIG++";
do "$projectroot/$project/$GITWEB_REPO_CONFIG"
if -e "$projectroot/$project/$GITWEB_CONFIG";
2. Put the configuration in config file, using/like %features support.
For example gitweb.committags.<committag name> would hold parameters
for <committag>. Committags sequence would be given by sequence of
entries in config file. Comittags without options would have sole
variable entry (which I think is equivalent to being bool variable
and having 1 or 'yes' as value).
The trouble with this approach is not overriding defaults provided
while still turning on/off specific committag. And of course the fact
that for that we need rather config reader in Perl (Git.pm or
gitweb).
What do you think about it? Junio? Pasky?
--
Jakub Narebski
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Jakub Narebski @ 2006-12-06 12:52 UTC (permalink / raw)
To: git
In-Reply-To: <4576A60A.3060003@gmail.com>
Liu Yubao wrote:
> I will try to run git in debugger, wish I can get the reason.
Or you can try to use GIT_TRACE.
--
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 12:56 UTC (permalink / raw)
To: git
In-Reply-To: <4576B8BC.8040107@xs4all.nl>
Han-Wen Nienhuys wrote:
> Subject: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
I like it... but could you check if you don't need to change
config.mak.in accordingly for ./configure script to generate proper
config.mak.autogen?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Andy Parkins @ 2006-12-06 12:55 UTC (permalink / raw)
To: git
In-Reply-To: <el6crv$p7e$1@sea.gmane.org>
On Wednesday 2006 December 06 12:27, Jakub Narebski wrote:
> This doesn't help newbies if they do "git pull" on branch other than
> "master". Git would fetch (a) from default remote "origin" (which can
> be unexpected a bit) (b) into current branch (which can be very
> unexpected for newbie) (c) the first branch in remote (which can be
> very unexpected).
That's why I was suggesting to remove the default behaviour when there is no
branch defined. In that case git-pull would just exit with an appropriate
message.
> Perhaps protected by config option and/or pull option... or perhaps not.
> Refuse pulling into current branch if it doesn.t have branch.<name>.remote
> matching current remote and doesn't have branch.<name>.merge entry, unless
> of course refspec is provided.
That's exactly what I meant; although your description is better.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: unmark after committing with git.el
From: Jakub Narebski @ 2006-12-06 12:58 UTC (permalink / raw)
To: git
In-Reply-To: <4576BB0B.9010200@xs4all.nl>
Han-Wen Nienhuys wrote:
> in the usual workflow, I mark a few files, and then commit, and then
> mark another few for commit.
>
> This patch removes the need to unmark between commits.
This should be in commit message.
>
> From ad694b33e033e3638043cd2d2970e6248beecb91 Mon Sep 17 00:00:00 2001
> From: Han-Wen Nienhuys <hanwen@xs4all.nl>
> Date: Wed, 6 Dec 2006 13:41:09 +0100
> Subject: [PATCH] git.el: unmark files in after committing.
>
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
But this break I think PCL-CVS behaviour compatibility. By the way,
[Backspace] should unmark all files.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: unmark after committing with git.el
From: Han-Wen Nienhuys @ 2006-12-06 13:09 UTC (permalink / raw)
To: git
In-Reply-To: <el6eku$vg7$3@sea.gmane.org>
Jakub Narebski escreveu:
> But this break I think PCL-CVS behaviour compatibility. By the way,
> [Backspace] should unmark all files.
it's M-DEL.
Is complete PCL-CVS compatibility a target?
From 62a005d36f97e9950c37a59ee5c976567d702d7a Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Wed, 6 Dec 2006 13:41:09 +0100
Subject: [PATCH] git.el: unmark files in after committing.
In the usual workflow, I mark a few files, and then commit, and then
mark another few for commit.
This patch removes the need to unmark between commits.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 972c402..642f7bb 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -596,7 +596,8 @@ and returns the process output as a string."
(git-run-command nil nil "rerere"))
(git-refresh-files)
(git-refresh-ewoc-hf git-status)
- (message "Committed %s." commit))
+ (message "Committed %s." commit)
+ (git-unmark-all))
(message "Commit aborted."))))
(message "No files to commit.")))
(delete-file index-file))))))
--
1.4.4.1.gc9922-dirty
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: "stgit clean" has problems with removed generated files
From: Catalin Marinas @ 2006-12-06 13:12 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20061123192831.GL5443@nan92-1-81-57-214-146.fbx.proxad.net>
On 23/11/06, Yann Dirson <ydirson@altern.org> wrote:
> On Thu, Nov 23, 2006 at 04:33:42PM +0000, Catalin Marinas wrote:
> > >First, when cleaning patches, we could first look up which patches are
> > >to be removed, and only pop the necessary ones.
I fixed this.
> > Is there any other place where ranges could be used but aren't?
>
> Hm, let's see... I'd say "export" (I have missed it already), "files"
> and maybe "commit" and "pick", although the latter would require a syntax
> for ranges in other branch.
I changed the export command to take a range of patches as arguments
(and a --dir option for the export directory).
> While reviewing the various commands for this, I realized that "stg pop
> <patch>" semantics is significantly different from "stg push <patch>" -
> ie. it is an equivalent of "goto". What about turning it into a
> float+pop, to better match the "push" behaviour ?
Thanks for the suggestion, I fixed pop to take patch ranges now.
> I also realized that "stg help <command>" output does not go through to
> the pager, while eg. the help for "mail" is quite long.
Added this feature as well. I'll try to push the changes tonight.
--
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Johannes Schindelin @ 2006-12-06 13:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el6d50$p7e$2@sea.gmane.org>
Hi,
On Wed, 6 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > + * Since every working tree contains a repository, a commit will not
> > + publish your changes; it will only create a revision. You have to
> > + "push" your changes to a public repository to make them visible
> > + to others.
> > +
>
> I'm not sure about context of this addition, but it is simply not
> true if you publish your working repository.
Remember, you are talking to CVS users. They are not dumb, but sooo used
to the CVS ways. So, they do not publish their working directory.
Later, when they became familiar with Git, you can tell them: "BTW you can
also publish your working directory, but then you have to be extra careful
with git-commit --amend, and if you allow pushing into your repo you have
to add hooks to prevent updating your current HEAD, etc."
Give them a chance to get used to the concepts of Git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Jakub Narebski @ 2006-12-06 13:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612061411380.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Hi!
Johannes Schindelin wrote:
> On Wed, 6 Dec 2006, Jakub Narebski wrote:
>
>> Johannes Schindelin wrote:
>>
>>> + * Since every working tree contains a repository, a commit will not
>>> + publish your changes; it will only create a revision. You have to
>>> + "push" your changes to a public repository to make them visible
>>> + to others.
>>> +
I'd perhaps add here that it doesn't "push" your changes to a repository
you cloned from / you fetch from.
>> I'm not sure about context of this addition, but it is simply not
>> true if you publish your working repository.
>
> Remember, you are talking to CVS users. They are not dumb, but sooo used
> to the CVS ways. So, they do not publish their working directory.
So we are talking in context of having CVS-like one central repository
from which they pull / fetch, and to which they push?
> Later, when they became familiar with Git, you can tell them: "BTW you can
> also publish your working directory, but then you have to be extra careful
> with git-commit --amend, and if you allow pushing into your repo you have
> to add hooks to prevent updating your current HEAD, etc."
I'd rather say that "publish your working repository", not "working
directory" here.
> Give them a chance to get used to the concepts of Git.
Well, it would be best to teach them concepts of git along.
--
Jakub Narebski
^ permalink raw reply
* New users, was Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Johannes Schindelin @ 2006-12-06 13:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612061427.58065.jnareb@gmail.com>
Hi,
On Wed, 6 Dec 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > Give them a chance to get used to the concepts of Git.
>
> Well, it would be best to teach them concepts of git along.
NOOOOO!
It might surprise you that most users are not at all interested in how Git
works. They just want to use the thing. And we should not try to make life
hard on them. Teach them what they have to know _as quickly as possible_
so that they can continue to work. They'll come back for more.
If you make it as complicated as Malbolge to them, you will never know you
lost a happy camper, because they _will not tell you_!
Ciao,
Dscho
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 14:16 UTC (permalink / raw)
To: git
In-Reply-To: <el6eh6$vg7$2@sea.gmane.org>
Jakub Narebski escreveu:
> Han-Wen Nienhuys wrote:
>
>> Subject: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
>
> I like it... but could you check if you don't need to change
> config.mak.in accordingly for ./configure script to generate proper
> config.mak.autogen?
I couldn't see anything, but while I was looking at it, I also added
support for non-srcdir builds. Can someone with a perl clue look over
the braindamaged messing-around with perl/perl.mak and figure out why
perl insists
make -C perl PERL_PATH='/usr/bin/perl' prefix='/tmp/test' perl.mak
make[1]: Entering directory `/home/lilydev/vc/go2/perl'
'/usr/bin/perl' -I/home/lilydev/vc/g2/perl /home/lilydev/vc/g2/perl/Makefile.PL FIRST_MAKEFILE='perl.mak' PREFIX='/tmp/test'
Could not open 'Git.pm': No such file or directory at /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm line 2649.
despite the -I option?
From 7bbd698891d9102fa26ae53848c9812f6d1b665e Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@lilypond.org>
Date: Wed, 6 Dec 2006 15:14:08 +0100
Subject: [PATCH] Allow non-srcdir builds using cd $builddir && $srcdir/configure
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
Makefile | 19 +++++++++++--------
config.mak.in | 5 +----
configure.ac | 31 ++++++++++++++++++++++++++++++-
generate-cmdlist.sh | 2 +-
perl/Makefile | 2 +-
5 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Makefile b/Makefile
index cb9b745..d64a5bd 100644
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ all:
#
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
- @$(SHELL_PATH) ./GIT-VERSION-GEN
+ @$(SHELL_PATH) $(srcdir)/GIT-VERSION-GEN
-include GIT-VERSION-FILE
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
@@ -120,7 +120,10 @@ datadir = $(prefix)/share
GIT_datadir = $(datadir)/git-core
gitexecdir = $(bindir)
template_dir = $(GIT_datadir)/templates/
-# DESTDIR=
+srcdir = .
+
+# this is usually set on the make command line.
+DESTDIR=
# default configuration for gitweb
GITWEB_CONFIG = gitweb_config.perl
@@ -598,8 +601,8 @@ git-merge-recur$X: git-merge-recursive$X
$(BUILT_INS): git$X
rm -f $@ && ln git$X $@
-common-cmds.h: Documentation/git-*.txt
- ./generate-cmdlist.sh > $@+
+common-cmds.h: $(wildcard $(srcdir)/Documentation/git-*.txt)
+ $(srcdir)/generate-cmdlist.sh $(srcdir)/Documentation/ > $@+
mv $@+ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -609,7 +612,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's!@@GIT_datadir@@!$(GIT_datadir)!g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
- $@.sh >$@+
+ $^ >$@+
chmod +x $@+
mv $@+ $@
@@ -630,7 +633,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@+
+ $^ >$@+
chmod +x $@+
mv $@+ $@
@@ -674,7 +677,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
- $@.sh > $@+
+ $< > $@+
chmod +x $@+
mv $@+ $@
@@ -821,7 +824,7 @@ install: all
fi
$(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
- $(INSTALL) -m755 git-sh-setup.sh '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
+ $(INSTALL) -m755 $(srcdir)/git-sh-setup.sh '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/config.mak.in b/config.mak.in
index 9a57840..902a392 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -2,7 +2,7 @@
# @configure_input@
CC = @CC@
-CFLAGS = @CFLAGS@
+CFLAGS = @CFLAGS@ -I.
AR = @AR@
TAR = @TAR@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
@@ -10,9 +10,6 @@ TAR = @TAR@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
-#gitexecdir = @libexecdir@/git-core/
-datarootdir = @datarootdir@
-template_dir = @datadir@/git-core/templates/
mandir=@mandir@
diff --git a/configure.ac b/configure.ac
index 34e3478..ccf9374 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,11 +5,13 @@ AC_PREREQ(2.59)
AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
AC_CONFIG_SRCDIR([git.c])
-
+srcdir=`cd $srcdir && pwd`
config_file=config.mak.autogen
config_append=config.mak.append
config_in=config.mak.in
+
+
echo "# ${config_append}. Generated by configure." > "${config_append}"
@@ -330,10 +332,37 @@ GIT_PARSE_WITH(iconv))
# change being considered an inode change from the update-cache perspective.
+
+
+
## Output files
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+
+## 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
## Cleanup
rm -f "${config_append}"
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 5450918..e744fbb 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -47,6 +47,6 @@ do
x
s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
p
- }' "Documentation/git-$cmd.txt"
+ }' "$1/git-$cmd.txt"
done
echo "};"
diff --git a/perl/Makefile b/perl/Makefile
index bd483b0..5706095 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,7 +29,7 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
- '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+ '$(PERL_PATH_SQ)' -I$(srcdir)/perl $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
endif
# this is just added comfort for calling make directly in perl dir
--
1.4.4.1.gc9922-dirty
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* git UI nit
From: Han-Wen Nienhuys @ 2006-12-06 14:22 UTC (permalink / raw)
To: git
When merging changes into a dirty working copy, one may get
..
Updating 62a005d..7bbd698
Makefile: needs update
README: needs update
config.mak.in: needs update
configure.ac: needs update
fatal: Entry 'Makefile' not uptodate. Cannot merge.
..
This is bad error message; "uptodate" suggests that Makefile is too old.
The problem is the reverse. The Makefile has been
edited and hence it is 'newer'.
This message should say
Entry 'Makefile' is dirty.
Revert or commit changes before merging
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: unmark after committing with git.el
From: Alexandre Julliard @ 2006-12-06 14:24 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <4576C0FB.8060000@xs4all.nl>
Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> Jakub Narebski escreveu:
>> But this break I think PCL-CVS behaviour compatibility. By the way,
>> [Backspace] should unmark all files.
>
> it's M-DEL.
>
> Is complete PCL-CVS compatibility a target?
As far as possible, yes. Note that you don't need to unmark the files
to do the next commit, the files you just committed should be in the
up-to-date state, and those are ignored when committing (and in most
other operations too).
--
Alexandre Julliard
^ permalink raw reply
* Re: git UI nit
From: Johannes Schindelin @ 2006-12-06 14:46 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <el6jmt$mej$1@sea.gmane.org>
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
>
> When merging changes into a dirty working copy, one may get
>
> ..
> Updating 62a005d..7bbd698
> Makefile: needs update
> README: needs update
> config.mak.in: needs update
> configure.ac: needs update
> fatal: Entry 'Makefile' not uptodate. Cannot merge.
> ..
>
>
> This is bad error message; "uptodate" suggests that Makefile is too old.
> The problem is the reverse. The Makefile has been
> edited and hence it is 'newer'.
Something like this?
-- snip --
[PATCH] Replace "needs update" by "dirty; needs commit"
This should clarify why a merge was not even started.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
read-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index eae4745..0d22de2 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -721,7 +721,7 @@ int refresh_cache(unsigned int flags)
}
if (quiet)
continue;
- printf("%s: needs update\n", ce->name);
+ printf("%s: dirty; needs commit\n", ce->name);
has_errors = 1;
continue;
^ permalink raw reply related
* Re: bug: git-sh-setup should not be in $PATH
From: Jakub Narebski @ 2006-12-06 14:51 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4576D0CB.7090408@xs4all.nl>
Han-Wen Nienhuys wrote::
> Jakub Narebski escreveu:
>> Han-Wen Nienhuys wrote:
>>
>>> Subject: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
>>
>> I like it... but could you check if you don't need to change
>> config.mak.in accordingly for ./configure script to generate proper
>> config.mak.autogen?
>
> I couldn't see anything, but while I was looking at it, I also added
> support for non-srcdir builds.
[...]
> From 7bbd698891d9102fa26ae53848c9812f6d1b665e Mon Sep 17 00:00:00 2001
> From: Han-Wen Nienhuys <hanwen@lilypond.org>
> Date: Wed, 6 Dec 2006 15:14:08 +0100
> Subject: [PATCH] Allow non-srcdir builds using cd $builddir && $srcdir/configure
Please add some longer commit message.
> Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
> ---
> Makefile | 19 +++++++++++--------
> config.mak.in | 5 +----
> configure.ac | 31 ++++++++++++++++++++++++++++++-
> generate-cmdlist.sh | 2 +-
> perl/Makefile | 2 +-
> 5 files changed, 44 insertions(+), 15 deletions(-)
[...]
> diff --git a/config.mak.in b/config.mak.in
> index 9a57840..902a392 100644
> --- a/config.mak.in
> +++ b/config.mak.in
[...]
> @@ -10,9 +10,6 @@ TAR = @TAR@
> prefix = @prefix@
> 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/
in config.mak.in
I have been told that setting 'datarootdir' is required to avoid
warnings with new versions of autoconf.
> diff --git a/configure.ac b/configure.ac
> index 34e3478..ccf9374 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -5,11 +5,13 @@ AC_PREREQ(2.59)
> AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
>
> AC_CONFIG_SRCDIR([git.c])
> -
> +srcdir=`cd $srcdir && pwd`
> config_file=config.mak.autogen
> config_append=config.mak.append
AC_CONFIG_SRCDIR should set 'srcdir' correctly.
> @@ -330,10 +332,37 @@ GIT_PARSE_WITH(iconv))
[...]
> +## 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.
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?
This part IMHO has no sense, and has no place here.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: J. Bruce Fields @ 2006-12-06 14:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <el6d50$p7e$2@sea.gmane.org>
On Wed, Dec 06, 2006 at 01:32:32PM +0100, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > + * Since every working tree contains a repository, a commit will not
> > + publish your changes; it will only create a revision. You have to
> > + "push" your changes to a public repository to make them visible
> > + to others.
> > +
>
> I'm not sure about context of this addition, but it is simply not
> true if you publish your working repository. Granted, usually one
> sets up bare public publishing repository...
That's true, but this document is focused on the cvs-like case of
multiple private repos pushing to a single common public repo.
But we could replace "a commit will not publish" by "a commit in your
private repository will not publish"--which would make the statement
true without distracting from the main point.
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Han-Wen Nienhuys @ 2006-12-06 14:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gpermus, hanwen, git
In-Reply-To: <Pine.LNX.4.63.0612061325320.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> It really is an important concept to grasp for people coming
> from CVS. Even if it is briefly mentioned, it is not obvious
> enough to sink in.
I think the goal is laudable, but IMO it would be better to shorten
the document rather adding more text.
here is my try
From 980a0ca1b274e1219c24c3138f95e42206c72875 Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@lilypond.org>
Date: Wed, 6 Dec 2006 15:50:13 +0100
Subject: [PATCH] another try at rephrasing cvs doc.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
Documentation/cvs-migration.txt | 34 +++++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 6812683..3270c57 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -6,24 +6,36 @@ this document is to put you on the road to recovery, by helping you
convert an existing cvs repository to git, and by showing you how to use a
git repository in a cvs-like fashion.
-Some basic familiarity with git is required. This
-link:tutorial.html[tutorial introduction to git] should be sufficient.
-
-First, note some ways that git differs from CVS:
+Git differs from CVS:
* Commits are atomic and project-wide, not per-file as in CVS.
- * Offline work is supported: you can make multiple commits locally,
+ * Branching is fast and easy.
+
+ * GIT is a distributed version control system:
+ This has several consequences:
+
+ - Every working tree contains a repository with a full copy of the
+ project history.
+
+ - Offline work is supported: you can create revisions locally,
then submit them when you're ready.
- * Branching is fast and easy.
+ Hence, there is a difference between creating a revision
+ (the "commit" command) and submitting it (the "push" command).
+
+ - No repository is inherently more important than
+ any other.
+
+ Of course, a project may still designate one central repository as
+ the True Master that contributors synchronize with.
+
+ See below for details.
- * Every working tree contains a repository with a full copy of the
- project history, and no repository is inherently more important than
- any other. However, you can emulate the CVS model by designating a
- single shared repository which people can synchronize with; see below
- for details.
+Some basic familiarity with git is required. This
+link:tutorial.html[tutorial introduction to git] should be sufficient.
+
Importing a CVS archive
-----------------------
--
1.4.4.1.gc9922-dirty
--
^ permalink raw reply related
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: J. Bruce Fields @ 2006-12-06 14:58 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Johannes Schindelin, gpermus, hanwen, git
In-Reply-To: <4576D92A.80307@xs4all.nl>
On Wed, Dec 06, 2006 at 03:52:26PM +0100, Han-Wen Nienhuys wrote:
> Johannes Schindelin escreveu:
> > It really is an important concept to grasp for people coming
> > from CVS. Even if it is briefly mentioned, it is not obvious
> > enough to sink in.
>
> I think the goal is laudable, but IMO it would be better to shorten
> the document rather adding more text.
OK, but...
> Documentation/cvs-migration.txt | 34 +++++++++++++++++++++++-----------
> 1 files changed, 23 insertions(+), 11 deletions(-)
... that lengthens it even more than the proposed addition.
> + Hence, there is a difference between creating a revision
> + (the "commit" command) and submitting it (the "push" command).
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.
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 15:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612061551.51603.jnareb@gmail.com>
Jakub Narebski escreveu:
> Please add some longer commit message.
do you have any specifics you would like me to mention?
>> 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.
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.
>> +## 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.
> 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.
--
^ permalink raw reply
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Han-Wen Nienhuys @ 2006-12-06 15:05 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, gpermus, hanwen, git
In-Reply-To: <20061206145802.GC1714@fieldses.org>
J. Bruce Fields escreveu:
> On Wed, Dec 06, 2006 at 03:52:26PM +0100, Han-Wen Nienhuys wrote:
>> Johannes Schindelin escreveu:
>>> It really is an important concept to grasp for people coming
>>> from CVS. Even if it is briefly mentioned, it is not obvious
>>> enough to sink in.
>> I think the goal is laudable, but IMO it would be better to shorten
>> the document rather adding more text.
>
> OK, but...
>
>> Documentation/cvs-migration.txt | 34 +++++++++++++++++++++++-----------
>> 1 files changed, 23 insertions(+), 11 deletions(-)
>
> ... that lengthens it even more than the proposed addition.
Yes, but with white space.
> 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.
As was mentioned in another thread, it make more sense to split this file up
into separate documents for project contributors and project admins.
--
^ permalink raw reply
* Re: git UI nit
From: Han-Wen Nienhuys @ 2006-12-06 15:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612061546190.28348@wbgn013.biozentrum.uni-wuerzburg.de>
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.
--
^ 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