* [PATCH v2] Windows: Fix intermittent failures of t7701
From: Johannes Sixt @ 2009-01-28 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3af3vnti.fsf@gitster.siamese.dyndns.org>
From: Johannes Sixt <j6t@kdbg.org>
The last test case checks whether unpacked objects receive the time stamp
of the pack file. Due to different implementations of stat(2) by MSYS and
our version in compat/mingw.c, the test fails in about half of the test
runs.
Note the following facts:
- The test uses perl's -M operator to compare the time stamps. Since we
depend on MSYS perl, the result of this operator is based on MSYS's
implementation of the stat(2) call.
- NTFS on Windows records fractional seconds.
- The MSYS implementation of stat(2) *rounds* fractional seconds to full
seconds instead of truncating them. This becomes obvious by comparing the
modification times reported by 'ls --full-time $f' and 'stat $f' for
various files $f.
- Our implementation of stat(2) in compat/mingw.c *truncates* to full
seconds.
The consequence of this is that
- add_packed_git() picks up a truncated whole second modification time
from the pack file time stamp, which is then used for the loose objects,
while the pack file retains its time stamp in fractional seconds;
- but the test case compared the pack file's rounded modification times
to the loose objects' truncated modification times.
And half of the time the rounded modification time is not the same as its
truncated modification time.
The fix is that we replace perl by 'test-chmtime -v +0', which prints the
truncated whole-second mtime without modifying it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Junio C Hamano schrieb:
> Care to reroll with the simpler, dumber but clearer version?
OK. This time I use an intermediate file and dquotes around $t.
-- Hannes
t/t7701-repack-unpack-unreachable.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index 63a8225..5babdf2 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -50,12 +50,10 @@ test_expect_success '-A with -d option leaves unreachable objects unpacked' '
compare_mtimes ()
{
- perl -e 'my $reference = shift;
- foreach my $file (@ARGV) {
- exit(1) unless(-f $file && -M $file == -M $reference);
- }
- exit(0);
- ' -- "$@"
+ read tref rest &&
+ while read t rest; do
+ test "$tref" = "$t" || break
+ done
}
test_expect_success '-A without -d option leaves unreachable objects packed' '
@@ -87,7 +85,9 @@ test_expect_success 'unpacked objects receive timestamp of pack file' '
tmppack=".git/objects/pack/tmp_pack" &&
ln "$packfile" "$tmppack" &&
git repack -A -l -d &&
- compare_mtimes "$tmppack" "$fsha1path" "$csha1path" "$tsha1path"
+ test-chmtime -v +0 "$tmppack" "$fsha1path" "$csha1path" "$tsha1path" \
+ > mtimes &&
+ compare_mtimes < mtimes
'
test_done
--
1.6.1.1.1203.g5882
^ permalink raw reply related
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Caleb Cushing @ 2009-01-28 9:53 UTC (permalink / raw)
To: Charles Bailey; +Cc: Junio C Hamano, git, Nanako Shiraishi
In-Reply-To: <20090128084756.GA28493@hashpling.org>
> With this change, it would seem to be more logical to ask whether the
> merge tool is to be run before creating the temporary files, removing
> the need for them to be cleaned up if the answer is no. I think that
> this would be cleaner overall.
I agree, but to be honest, I couldn't get the logic wrapped around my
head, so I did it this way. refactoring does seem to be the best idea,
but I don't understand enough of it yet to do so.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCHv4] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 10:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200901280247.25317.jnareb@gmail.com>
On Wed, Jan 28, 2009 at 2:47 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 28 Jan 2009, Junio C Hamano wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>> > When PATH_INFO is defined,
>
> I other words: when using PATH_INFO gitweb URL
Notice that gitweb accepts PATH_INFO even whe it's not set to produce them
>> > static files such as the default CSS or the
>> > shortcut icon are not accessible beyond the summary page (e.g. in
>> > shortlog or commit view).
>
> To be more exact: if static files, such as the default CSS (and also
> other stylesheets, if defined), the gitweb favicon / shortcut icon,
> or the gitweb logo locations (URIs) are defined using relative URL
> with relative path (and default Makefile rule to generate gitweb.cgi
> uses basenames like 'gitweb.css', which are relative paths) _THEN_
> those static files are not accessible beyond 'summary' and projects
> list view (e.g. in 'shortlog' or 'commit' view).
I'll rewrite the commit message.
>> >
>> > Fix this by adding a <base> tag pointing to the script's own URL.
>
> Which defines base URL for all relative links in gitweb.
(is this one really necessary)
> /Note that this makes the document hierarchy non-portable, but I don't
> think we care.../
In what sense it becomes non-portable?
>> > + if ($ENV{'PATH_INFO'}) {
>> > + print "<base href=\"$my_url\" />\n";
>> > + }
>>
>> Perhaps this is a stupid question, but is $my_url already safe to include
>> in the output without any further quoting at this point in the codepath?
>
> Hmmmm... to be safe we probably should use either esc_url($my_url) here
> (like in git_feed subroutine).
I"ll do that.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git clone ssh:// auth failiure
From: Johannes Gilger @ 2009-01-28 10:06 UTC (permalink / raw)
To: git
In-Reply-To: <197294.49807.qm@web35708.mail.mud.yahoo.com>
On 2009-01-28, Arya, Manish Kumar <m.arya@yahoo.com> wrote:
> root@dcb0:~# git clone ssh://localhost/~/testproject manish
You are aware that youre calling ssh as root, and that ssh will try to
login to localhost as user "root"? A lot of sshd installations do not
allow this by default.
> Permission denied
> (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
This is an ssh-error, has nothing to do with git
Greetings, Jojo (from a Nokia N810, yuk)
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* (beginner) git rm
From: Zabre @ 2009-01-28 10:11 UTC (permalink / raw)
To: git
Hi,
I am learning git and there is something I don't get : why a file deleted in
a branch gets also deleted in my master?
(For the moment I'm only working locally, no remote repository)
I have a master branch containing 4 text files called a.txt , b.txt , c.txt
, d.txt . (in HEAD)
I create a new branch from there (masters HEAD) and go to this new branch.
$ git branch new
$ git checkout new
I delete one file in the new branch
$ git rm d.txt
$ ls
a.txt b.txt c.txt
Then I go back to the master branch and list the files there
$ git checkout master
$ls
a.txt b.txt c.txt
I have not modified the master branch, why is d.txt deleted there also?
There must be something I did not understand in git behaviour (something to
do with the index?)
Thank you for your help.
--
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231416.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v2 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Sverre Rabbelier @ 2009-01-28 10:32 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <7vhc3kxdwm.fsf@gitster.siamese.dyndns.org>
Heya,
On Wed, Jan 28, 2009 at 05:17, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>> + test $# = 0 && test -t 0 && usage
Awesome! Thanks for looking into this :).
> Sorry to be dense. Why isn't your patch the above single liner?
I hope you two work this out soon so it gets into maint.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: (beginner) git rm
From: Peter Krefting @ 2009-01-28 10:36 UTC (permalink / raw)
To: Zabre; +Cc: Git Mailing List
In-Reply-To: <1233137498146-2231416.post@n2.nabble.com>
Zabre:
> I delete one file in the new branch
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt
Here you have not yet committed the change, so the change is only in
the staging area. You need to
git commit
to create a commit on your branch.
> Then I go back to the master branch and list the files there
> $ git checkout master
Since you have not yet made any commits to your branch, master and new
both point to the same commit, meaning that this is does nothing but
changes which branch you are committing to.
> $ls
> a.txt b.txt c.txt
You are in the same place as you were a moment ago, but you have told
Git that you want to commit the removal to master instead of new.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Is the stgit project still alive?
From: Catalin Marinas @ 2009-01-28 10:37 UTC (permalink / raw)
To: J Robert Ray; +Cc: Git Mailing List
In-Reply-To: <20090128-041237.sv13413.72217@gna.org>
(I cc'ed the git list as well for the information)
2009/1/28 J Robert Ray <jrobertray@gmail.com>:
> The project website appears to have died.
I noticed this as well. I was hosting the website at freezend.com and
they seem to have problems:
http://www.freewebspace.net/forums/showthread.php?p=1049536
I moved it somewhere else yesterday and http://www.procode.org/ works
now but I still have to transfer the StGit files as well, sometime
this week.
The project page is fine - https://gna.org/projects/stgit/ - and
developing activity going on (I was just too busy to fix some of the
bugs logged and release a new version;we'll hopefully get one in
February).
--
Catalin
^ permalink raw reply
* [PATCHv4 2/2] gitweb: webserver config for PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 10:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1233139832-24124-1-git-send-email-giuseppe.bilotta@gmail.com>
Document some possible Apache configurations when the path_info feature
is enabled in gitweb.
---
So I decided to document the best way to set up the web server with the
path_info feature. I particularly like the second trick, although I haven't
found a way to make git-daemon accept both git://git.example.com/project and
git://git.example.com/project.git when the project dirs don't have the .git
extensions (e.g. /pub/git/project instead of /pub/git/project.git)
gitweb/README | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 825162a..52ad88b 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -322,6 +322,82 @@ something like the following in your gitweb.conf (or gitweb_config.perl) file:
$home_link = "/";
+PATH_INFO usage
+-----------------------
+If you enable PATH_INFO usage in gitweb by putting
+
+ $feature{'pathinfo'}{'default'} = [1];
+
+in your gitweb.conf, it is possible to set up your server so that it
+consumes and produces URLs in the form
+
+http://git.example.com/project.git/shortlog/sometag
+
+by using a configuration such as the following, that assumes that
+/var/www/gitweb is the DocumentRoot of your webserver, and that it
+contains the gitweb.cgi script and complementary static files
+(stylesheet, favicon):
+
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+
+The rewrite rule guarantees that existing static files will be properly
+served, whereas any other URL will be passed to gitweb as PATH_INFO
+parameter.
+
+Notice that in this case you don't need special settings for
+@stylesheets, $my_uri and $home_link, but you lose "dumb client" access
+to your project .git dirs. A possible workaround for the latter is the
+following: in your project root dir (e.g. /pub/git) have the projects
+named without a .git extension (e.g. /pub/git/project instead of
+/pub/git/project.git) and configure Apache as follows:
+
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ AliasMatch ^(/.*?)(\.git)(/.*)? /pub/git$1$3
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+
+The additional AliasMatch makes it so that
+
+http://git.example.com/project.git
+
+will give raw access to the project's git dir (so that the project can
+be cloned), while
+
+http://git.example.com/project
+
+will provide human-friendly gitweb access.
+
+
Originally written by:
Kay Sievers <kay.sievers@vrfy.org>
--
1.5.6.5
^ permalink raw reply related
* [PATCHv4 1/2] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-28 10:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When gitweb is invoked with PATH_INFO and links to static files such as
the CSS and favicon/shortcut icon are relative URLs with relative paths
(as is the case when using the default Makefile), these files are not
accessible beyond the project list and summary page (e.g. in shortlog or
commit view).
Fix this by adding a <base> tag pointing to the script's own URL, that
ensure that all relative paths will be based on this.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..f7aaf9a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,11 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we
+# set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ print "<base href='".esc_url($my_url)."' />\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Re: (beginner) git rm
From: Zabre @ 2009-01-28 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0901281133380.645@ds9.cixit.se>
Peter Krefting wrote:
>
> Here you have not yet committed the change, so the change is only in
> the staging area. You need to
>
> git commit
>
> to create a commit on your branch.
>
Thank you Peter.
I've just done a hard reset and redid it the right way. It worked as
expected.
$ git checkout new
$ rm d.txt
$ git rm d.txt
$ git commit
I am a little bit confused regarding rm : first I did a simple "rm" but git
would not commit, so I had to "git rm" for the index to be modified and have
something to commit. Is this the right way to do things?
Another question would be : instead of doing a hard reset (I might have
other changes in the index that I don't want to loose) is it possible to
remove only one "delete action" from the index?
--
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231622.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: (beginner) git rm
From: Tomas Carnecky @ 2009-01-28 11:37 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233140751523-2231622.post@n2.nabble.com>
On 01/28/2009 12:05 PM, Zabre wrote:
> Another question would be : instead of doing a hard reset (I might have
> other changes in the index that I don't want to loose) is it possible to
> remove only one "delete action" from the index?
Do you mean 'undelete' a file? git checkout d.txt - That restores the
file in the working tree and resets the index just for that file.
tom
^ permalink raw reply
* Re: (beginner) git rm
From: Zabre @ 2009-01-28 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <49804385.908@dbservice.com>
Tomas Carnecky wrote:
>
> Do you mean 'undelete' a file? git checkout d.txt - That restores the
> file in the working tree and resets the index just for that file.
>
Hi Tom,
(thank you for your interest in my newbie problems)
yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
But I did not manage to apply your solution succesfully :
$ git rm d.txt
$ ls
a.txt b.txt c.txt
$ git status
# On branch new
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: d.txt
#
$ git checkout d.txt
error: pathspec 'mamma.txt' did not match any file(s) known to git.
Did you forget to 'git add'?
So it did not work but I've just noticed that unstage tip given by the
status command, and I did the following (which worked)
$ git reset HEAD d.txt
d.txt: needs update
$ ls
a.txt b.txt c.txt
$ git checkout d.txt
$ ls
a.txt b.txt c.txt d.txt
Reading the git reset help file gives me the feeling I should use this with
caution... It looks like you can somehow modify the change history.
Anyway these two commands helped me change the index the way I wanted.
Please tell me if this might somehow go wrong in another situation.
--
View this message in context: http://n2.nabble.com/%28beginner%29-git-rm-tp2231416p2231849.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: (beginner) git rm
From: Tomas Carnecky @ 2009-01-28 12:19 UTC (permalink / raw)
To: Zabre; +Cc: git
In-Reply-To: <1233144045221-2231849.post@n2.nabble.com>
On 01/28/2009 01:00 PM, Zabre wrote:
>
> Tomas Carnecky wrote:
>> Do you mean 'undelete' a file? git checkout d.txt - That restores the
>> file in the working tree and resets the index just for that file.
>>
>
> Hi Tom,
> (thank you for your interest in my newbie problems)
>
> yes that's what I mean : 'undelete' a file, after a "git rm d.txt".
> But I did not manage to apply your solution succesfully :
> $ git rm d.txt
> $ ls
> a.txt b.txt c.txt
> $ git status
> # On branch new
> # Changes to be committed:
> # (use "git reset HEAD<file>..." to unstage)
> #
> # deleted: d.txt
> #
> $ git checkout d.txt
> error: pathspec 'mamma.txt' did not match any file(s) known to git.
> Did you forget to 'git add'?
Oops, sorry. git checkout HEAD -- d.txt
You have to tell which version of d.txt you want. In your case the
version in HEAD.
tom
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Schindelin @ 2009-01-28 12:43 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <20090128042814.GA18216@coredump.intra.peff.net>
Hi,
On Tue, 27 Jan 2009, Jeff King wrote:
> On Tue, Jan 27, 2009 at 05:42:03PM +0100, Johannes Schindelin wrote:
>
> > > We want to catch failures of test-chmtime; but since it appears in a
> > > pipe, we cannot access its exit code. Therefore, we at least make sure
> > > that it prints time stamps of all files that are passed on its command
> > > line.
> >
> > I use this trick in my valgrind series:
> >
> > ($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
> > test 0 = "$(cat exit.code)"
>
> Oh, that's far too readable. How about:
>
> exec 3>&1
> status=$( ( ($PROGRAM ; echo $? >&4) | $OTHER_PROGRAM >&3) 4>&1 )
> exec 3>&-
>
> But seriously, I think if we are talking about tests, then
>
> $PROGRAM >output &&
> $OTHER_PROGRAM <output
>
> is very clear to read, and as a bonus makes "output" accessible for
> viewing when the test breaks.
The real problem is that in my case, OTHER_PROGRAM=tee.
But you're right, Hannes was talking about tests, where it might
even make sense to have a record of what was passed between the
two programs.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add --ff-only flag to git-merge
From: Yuval Kogman @ 2009-01-28 12:53 UTC (permalink / raw)
To: git; +Cc: Yuval Kogman
This patch adds an --ff-only flag to git-merge. When specified git-merge
will exit with an error whenver a merge will not be a simple fast
forward, similar to the default behavior of git push.
---
builtin-merge.c | 6 ++++++
t/t7600-merge.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e4555b0..d37423b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -44,6 +44,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, option_log, squash;
static int option_commit = 1, allow_fast_forward = 1;
static int allow_trivial = 1, have_message;
+static int only_fast_forward;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
static unsigned char head[20], stash[20];
@@ -167,6 +168,8 @@ static struct option builtin_merge_options[] = {
"perform a commit if the merge succeeds (default)"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast forward (default)"),
+ OPT_BOOLEAN(0, "ff-only", &only_fast_forward,
+ "allow only fast forward"),
OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
"merge strategy to use", option_parse_strategy),
OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -1012,6 +1015,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
finish(o->sha1, msg.buf);
drop_save();
return 0;
+ } else if ( only_fast_forward ) {
+ printf("Merge is non fast forward, aborting.\n");
+ return 1;
} else if (!remoteheads->next && common->next)
;
/*
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..6c2febc 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -234,6 +234,8 @@ test_expect_success 'reject non-strategy with a git-merge-foo name' '
test_must_fail git merge -s index c1
'
+test_debug 'gitk --all'
+
test_expect_success 'merge c0 with c1' '
git reset --hard c0 &&
git merge c1 &&
@@ -243,6 +245,15 @@ test_expect_success 'merge c0 with c1' '
test_debug 'gitk --all'
+test_expect_success 'merge c0 with c1 (fast forward only)' '
+ git reset --hard c0 &&
+ git merge --ff-only c1 &&
+ verify_merge file result.1 &&
+ verify_head "$c1"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2' '
git reset --hard c1 &&
test_tick &&
@@ -253,6 +264,14 @@ test_expect_success 'merge c1 with c2' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2' '
+ git reset --hard c1 &&
+ test_tick &&
+ test_must_fail git merge --ff-only c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 and c3' '
git reset --hard c1 &&
test_tick &&
@@ -263,6 +282,14 @@ test_expect_success 'merge c1 with c2 and c3' '
test_debug 'gitk --all'
+test_expect_success 'merge c1 with c2 and c3 (fast forward only' '
+ git reset --hard c1 &&
+ test_tick &&
+ test_must_fail git merge --ff-only c2 c3
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c0 with c1 (no-commit)' '
git reset --hard c0 &&
git merge --no-commit c1 &&
@@ -470,6 +497,15 @@ test_expect_success 'merge c1 with c0, c2, c0, and c1' '
test_debug 'gitk --all'
+test_expect_success 'merge fast forward only' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "" &&
+ test_tick &&
+ test_must_fail git merge --ff-only c0 c2 c0 c1
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c0, c2, c0, and c1' '
git reset --hard c1 &&
git config branch.master.mergeoptions "" &&
@@ -481,6 +517,15 @@ test_expect_success 'merge c1 with c0, c2, c0, and c1' '
test_debug 'gitk --all'
+test_expect_success 'merge fast forward only' '
+ git reset --hard c1 &&
+ git config branch.master.mergeoptions "" &&
+ test_tick &&
+ test_must_fail git merge --ff-only c1 c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c1 and c2' '
git reset --hard c1 &&
git config branch.master.mergeoptions "" &&
--
1.6.1
^ permalink raw reply related
* Re: (beginner) git rm
From: Theodore Tso @ 2009-01-28 13:03 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Zabre, git
In-Reply-To: <49804D41.3010801@dbservice.com>
On Wed, Jan 28, 2009 at 01:19:13PM +0100, Tomas Carnecky wrote:
>
> Oops, sorry. git checkout HEAD -- d.txt
> You have to tell which version of d.txt you want. In your case the
> version in HEAD.
>
I use this command enough that I have this defined as an alias in my
~/.gitconfig file. Try running this command:
git config --global alias.revert-file "checkout HEAD --"
Now you will be able to do this:
git revert-file d.txt
This is also useful when I've edited d.txt, and decided that I didn't
go about it the right away, and so I want to revert my edits.
- Ted
^ permalink raw reply
* Re: [PATCH] Add --ff-only flag to git-merge
From: Johannes Schindelin @ 2009-01-28 13:26 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
In-Reply-To: <1233147238-30082-1-git-send-email-nothingmuch@woobling.org>
Hi,
On Wed, 28 Jan 2009, Yuval Kogman wrote:
> @@ -1012,6 +1015,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> finish(o->sha1, msg.buf);
> drop_save();
> return 0;
> + } else if ( only_fast_forward ) {
> + printf("Merge is non fast forward, aborting.\n");
> + return 1;
> } else if (!remoteheads->next && common->next)
If you compare the two if() lines, you will see that you mixed style.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --ff-only flag to git-merge
From: Yuval Kogman @ 2009-01-28 13:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901281425180.3586@pacific.mpi-cbg.de>
2009/1/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> If you compare the two if() lines, you will see that you mixed style.
Thanks,
I will be fixing it here:
http://github.com/nothingmuch/git/tree/ff-only
before I send a new version, as I likely screwed up many things, not
just that =)
^ permalink raw reply
* Re: [PATCH v2 2/2] git-am: minor cleanups
From: Jay Soffian @ 2009-01-28 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sverre
In-Reply-To: <7vd4e8xdva.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 11:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Use "test -t 0" instead of deprecated "tty -s" to detect when stdin is a
>> terminal.
>
> Who deprecated it?
I believe it's IEEE Std 1003.2-1992 / POSIX.2. I found the initial
reference in the BSD/OS X man page[1], but google also found me other
references [2,3]. Also, elsewhere git uses "test -t 0", not "tty -s".
[1] http://developer.apple.com/DOCUMENTATION/Darwin/Reference/ManPages/man1/tty.1.html
(The -s option is deprecated in favor of the ``test -t 0'' command.)
[2] http://docs.sun.com/app/docs/doc/816-5165/tty-1?a=view
(Portable applications should use test -t.)
[3] http://opengroup.org/onlinepubs/007908799/xcu/tty.html
(Portable applications should use test -t 0.)
j.
^ permalink raw reply
* Re: [PATCH v2 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 14:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sverre
In-Reply-To: <7vhc3kxdwm.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 11:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> + test $# = 0 && test -t 0 && usage
>
> Sorry to be dense. Why isn't your patch the above single liner?
>
"Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
while it is processing input, but not if mailsplit exits non-zero due to
error."
j.
^ permalink raw reply
* Re: [PATCH] Add --ff-only flag to git-merge
From: Sverre Rabbelier @ 2009-01-28 14:35 UTC (permalink / raw)
To: Yuval Kogman; +Cc: git
In-Reply-To: <1233147238-30082-1-git-send-email-nothingmuch@woobling.org>
On Wed, Jan 28, 2009 at 13:53, Yuval Kogman <nothingmuch@woobling.org> wrote:
> This patch adds an --ff-only flag to git-merge. When specified git-merge
> will exit with an error whenver a merge will not be a simple fast
> forward, similar to the default behavior of git push.
I like! This calls for a new alias 'git config alias.integrate "merge
--no-ff"', thanks!
*hopes this hits next soon*
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH v3 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 15:03 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
When git am is called w/o arguments, w/o a patch on stdin and the user hits
ctrl-c, it leaves behind a partially populated $dotest directory. After this
commit, it emits usage when called w/o arguments and w/o a patch on stdin.
Noticed by Sverre Rabbelier
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v2: make Junio happy by no longer removing $dotest if git-am is
interupted while mailsplit is running.
git-am.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b1c05c9..92a64b2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -254,6 +254,7 @@ else
done
shift
fi
+ test $# = 0 && test -t 0 && usage
git mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || {
rm -fr "$dotest"
exit 1
--
1.6.1.224.gb56c
^ permalink raw reply related
* [PATCH v3 2/2] git-am: minor cleanups
From: Jay Soffian @ 2009-01-28 15:03 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
In-Reply-To: <1233154990-19745-1-git-send-email-jaysoffian@gmail.com>
Update usage statement to remove a no-longer supported option, and to hide two
options (one a no-op, one internal) unless --help-all is used.
Use "test -t 0" instead of "tty -s" to detect when stdin is a terminal. (test
-t 0 is used elsewhere in git-am and in other git shell scripts, tty -s is
not, and appears to be deprecated by POSIX)
Use "test ..." instead of "[ ... ]" and "die <msg>" instead of "echo <msg>
>&2; exit 1" to be consistent with rest of script.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v2: mention who deprecated "tty -s" in commit message.
git-am.sh | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 92a64b2..670fc02 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -8,9 +8,8 @@ OPTIONS_SPEC="\
git am [options] [<mbox>|<Maildir>...]
git am [options] (--resolved | --skip | --abort)
--
-d,dotest= (removed -- do not use)
i,interactive run interactively
-b,binary (historical option -- no-op)
+b,binary* (historical option -- no-op)
3,3way allow fall back on 3way merging if needed
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
@@ -24,7 +23,7 @@ resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
abort restore the original branch and abort the patching operation.
-rebasing (internal use for git-rebase)"
+rebasing* (internal use for git-rebase)"
. git-sh-setup
prefix=$(git rev-parse --show-prefix)
@@ -204,7 +203,7 @@ then
# unreliable -- stdin could be /dev/null for example
# and the caller did not intend to feed us a patch but
# wanted to continue unattended.
- tty -s
+ test -t 0
;;
*)
false
@@ -281,10 +280,7 @@ fi
case "$resolved" in
'')
files=$(git diff-index --cached --name-only HEAD --) || exit
- if [ "$files" ]; then
- echo "Dirty index: cannot apply patches (dirty: $files)" >&2
- exit 1
- fi
+ test "$files" && die "Dirty index: cannot apply patches (dirty: $files)"
esac
if test "$(cat "$dotest/utf8")" = t
--
1.6.1.224.gb56c
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-28 15:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Mike Ralphson, git
In-Reply-To: <20090128074204.GA31951@coredump.intra.peff.net>
On Jan 28, 2009, at 1:42 AM, Jeff King wrote:
> On Tue, Jan 27, 2009 at 11:37:21PM -0800, Junio C Hamano wrote:
>
>>>> Just to be sure we are on the same page. My directory structure
>>>> has a
>>>> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is
>>>> the
>>>> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
>>>> then do: ../../src/git-1.6.1/configure <options> After this
>>>> completes, you can do "make".
>>>
>>> I don't see how this would work without automake support, which
>>> git does
>>> not have.
>>
>> ... nor want to have ;-).
>
> Heh. Yes, in case there was any confusion: I don't want my statement
> in
> any way to be construed as a suggestion to support automake.
>
> I would not be opposed to it if it somehow enhanced some users'
> experience without bothering people who didn't want to touch it (like
> the way that autoconf support is implemented). But I don't see how
> that
> would be possible.
Thats fine. I didn't know if this was a "known" situation or not so I
just mentioned it.
As I mentioned, most open source code supports this style of build. I
have no idea
what it would take to get it to work.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox