* Re: Using the --track option when creating a branch
From: Sam Vilain @ 2008-10-30 5:12 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18696.32778.842933.486171@lisa.zopyra.com>
On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
> We use git in a way that makes it desirable for us to only push/pull
> to the same remote branch. So, if I'm in branch X, I want 'git push'
> to push to origin/X, and 'git pull' to fetch into origin/X and then
> merge into X from origin/X.
>
> In other words, we want git push/pull to behave in branches other than
> master the same way it does when in master.
>
> I have discovered the '--track' option when creating a local branch,
> and this appears to me to be the thing that gives us the desired
> behavior.
As things currently stand this is not achievable behaviour. The
behaviour of 'git push' is to push all matching refs. If you are lucky
this is what you intended, but it also pushes any changes to *other*
branches that you have made.
I have tabled a change proposal to make it work as you suggest in a
separate thread.
Sam
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Ping Yin @ 2008-10-30 6:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <46dff0320810240630s5cbfa62esd10a9da45ce37bf8@mail.gmail.com>
On Fri, Oct 24, 2008 at 9:30 PM, Ping Yin <pkufranky@gmail.com> wrote:
> On Fri, Oct 24, 2008 at 8:54 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Ping Yin venit, vidit, dixit 24.10.2008 14:37:
>>> So what should i do if i want it added as text file?
>>
>> You should give us more detail on the file ;)
>> What's the extension, what's the typical content? It may be a simple
>> matter of specifying attributes.
>> Do ordinary diff and grep recognize your files as text?
>>
>> Michael
>>
>
> It's just an xml file. I guess maybe there are some hidden characters
> at the beginning. I will figure it out later because i have no access
> to that file right now.
>
> Ping Yin
>
I have figured it out. It's just because the BOM characters feff00 in
the beginning of the utf-8 xml file.
--
Ping Yin
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-10-30 7:26 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano, René Scharfe
In-Reply-To: <20081029215444.GA19874@sigill.intra.peff.net>
Jeff King, Wed, Oct 29, 2008 22:54:45 +0100:
> On Wed, Oct 29, 2008 at 11:38:32AM +0100, Alex Riesen wrote:
>
> > There can be a problem with "-printf": Open Group SUS does not specify
> > -printf for find(1), so it is probably a problem somewhere. I just don't know.
> > [...]
> > + find extract/a/a -printf "%T@\\n" >b.mtime &&
>
> $ uname -sr
> FreeBSD 6.1-RELEASE-p17-jc1
> $ find . -printf "%T@\\n"
> find: -printf: unknown option
>
> > There is always a fallback, which is to write a small program which calls
> > native stat(2). Or modify test-chmtime to just print mtime when asked.
>
> I think that makes the most sense.
>
Ok, will do.
^ permalink raw reply
* Re: Encoding problems using git-svn
From: Eric Wong @ 2008-10-30 7:41 UTC (permalink / raw)
To: James North; +Cc: git
In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com>
Hi James,
I saw your other patch too late, I had already started working on my
patch earlier today but got distracted by other things (being at
GitTogether :) and lacked a stable Internet connection afterwards.
Anyways, here's my version, it handles the case where the user specifies
the --edit option to interactively edit the commit message before
committing; and also reencodes the messages when fetching from SVN.
Can you let me know if it works for you?
Note: I'll be in transit tomorrow and may not have time to follow
up on this until Saturday.
>From 84f003e0c39414ebf27a98de167643e95bed6abb Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Wed, 29 Oct 2008 23:49:26 -0700
Subject: [PATCH] git-svn: respect i18n.commitencoding config
SVN itself always stores log messages in the repository as
UTF-8. git always stores/retrieves everything as raw binary
data with no transformations whatsoever.
To interact with SVN, we need to encode log messages as UTF-8
before sending them to SVN, as SVN cannot do it for us. When
retrieving log messages from SVN, we also need to (attempt to)
reencode the UTF-8 log message back to the user-specified commit
encoding.
Note, handling i18n.logoutputencoding for "git svn log" also
needs to be done in a future change.
Also, this change only deals with the encoding of commit
messages and nothing else (path names, blob content, ...).
In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com>
James North <tocapicha@gmail.com> wrote:
> Hi,
>
> I'm using git-svn on a system with ISO-8859-1 encoding. The problem is
> when I try to use "git svn dcommit" to send changes to a remote svn
> (also ISO-8859-1).
>
> Seems like git-svn is sending commit messages with utf-8 (just a
> guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a
> de cami?\243n"
>
> I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the
> warning when doing "git svn dcommit" but messages still are sent with
> wrong encoding.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 24 ++++++++-
t/t9129-git-svn-i18n-commitencoding.sh | 80 ++++++++++++++++++++++++++++++++
2 files changed, 101 insertions(+), 3 deletions(-)
create mode 100755 t/t9129-git-svn-i18n-commitencoding.sh
diff --git a/git-svn.perl b/git-svn.perl
index f90ddac..f24559c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1136,9 +1136,19 @@ sub get_commit_entry {
system($editor, $commit_editmsg);
}
rename $commit_editmsg, $commit_msg or croak $!;
- open $log_fh, '<', $commit_msg or croak $!;
- { local $/; chomp($log_entry{log} = <$log_fh>); }
- close $log_fh or croak $!;
+ {
+ # SVN requires messages to be UTF-8 when entering the repo
+ local $/;
+ open $log_fh, '<', $commit_msg or croak $!;
+ binmode $log_fh;
+ chomp($log_entry{log} = <$log_fh>);
+
+ if (my $enc = Git::config('i18n.commitencoding')) {
+ require Encode;
+ Encode::from_to($log_entry{log}, $enc, 'UTF-8');
+ }
+ close $log_fh or croak $!;
+ }
unlink $commit_msg;
\%log_entry;
}
@@ -2273,6 +2283,14 @@ sub do_git_commit {
}
defined(my $pid = open3(my $msg_fh, my $out_fh, '>&STDERR', @exec))
or croak $!;
+ binmode $msg_fh;
+
+ # we always get UTF-8 from SVN, but we may want our commits in
+ # a different encoding.
+ if (my $enc = Git::config('i18n.commitencoding')) {
+ require Encode;
+ Encode::from_to($log_entry->{log}, 'UTF-8', $enc);
+ }
print $msg_fh $log_entry->{log} or croak $!;
restore_commit_header_env($old_env);
unless ($self->no_metadata) {
diff --git a/t/t9129-git-svn-i18n-commitencoding.sh b/t/t9129-git-svn-i18n-commitencoding.sh
new file mode 100755
index 0000000..2848e46
--- /dev/null
+++ b/t/t9129-git-svn-i18n-commitencoding.sh
@@ -0,0 +1,80 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Eric Wong
+
+test_description='git svn honors i18n.commitEncoding in config'
+
+. ./lib-git-svn.sh
+
+compare_git_head_with () {
+ nr=`wc -l < "$1"`
+ a=7
+ b=$(($a + $nr - 1))
+ git cat-file commit HEAD | sed -ne "$a,${b}p" >current &&
+ test_cmp current "$1"
+}
+
+compare_svn_head_with () {
+ LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
+ sed -e 1,3d -e "/^-\+\$/d" >current &&
+ test_cmp current "$1"
+}
+
+for H in ISO-8859-1 EUCJP ISO-2022-JP
+do
+ test_expect_success "$H setup" '
+ mkdir $H &&
+ svn import -m "$H test" $H "$svnrepo"/$H &&
+ git svn clone "$svnrepo"/$H $H
+ '
+done
+
+for H in ISO-8859-1 EUCJP ISO-2022-JP
+do
+ test_expect_success "$H commit on git side" '
+ (
+ cd $H &&
+ git config i18n.commitencoding $H &&
+ git checkout -b t refs/remotes/git-svn &&
+ echo $H >F &&
+ git add F &&
+ git commit -a -F "$TEST_DIRECTORY"/t3900/$H.txt &&
+ E=$(git cat-file commit HEAD | sed -ne "s/^encoding //p") &&
+ test "z$E" = "z$H"
+ compare_git_head_with "$TEST_DIRECTORY"/t3900/$H.txt
+ )
+ '
+done
+
+for H in ISO-8859-1 EUCJP ISO-2022-JP
+do
+ test_expect_success "$H dcommit to svn" '
+ (
+ cd $H &&
+ git svn dcommit &&
+ git cat-file commit HEAD | grep git-svn-id: &&
+ E=$(git cat-file commit HEAD | sed -ne "s/^encoding //p") &&
+ test "z$E" = "z$H" &&
+ compare_git_head_with "$TEST_DIRECTORY"/t3900/$H.txt
+ )
+ '
+done
+
+test_expect_success 'ISO-8859-1 should match UTF-8 in svn' '
+(
+ cd ISO-8859-1 &&
+ compare_svn_head_with "$TEST_DIRECTORY"/t3900/1-UTF-8.txt
+)
+'
+
+for H in EUCJP ISO-2022-JP
+do
+ test_expect_success '$H should match UTF-8 in svn' '
+ (
+ cd $H &&
+ compare_svn_head_with "$TEST_DIRECTORY"/t3900/2-UTF-8.txt
+ )
+ '
+done
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: request for pre-generated git.info pages
From: Mike Ralphson @ 2008-10-30 9:06 UTC (permalink / raw)
To: SLONIK.AZ, Git Mailing List; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <ee2a733e0810291500o67b3f94fibef63e0a173e8cc1@mail.gmail.com>
2008/10/29 Leo Razoumov <slonik.az@gmail.com>:
> I am an emacs user but with my current setup I have difficulties
> generating git.info pages. Main Git repo already provides
> pre-generated man and html documentation in "man" and "html"
> branches. I would kindly beg to extend this privilege to "info" pages
> to benefit all the emacs users out there.
Unfortunately I don't have a working asciidoc etc toolchain either
(though I will take a look at getting it working on my central git box
which is Linux based). As I'm not an emacs or Info user I probably
wouldn't know if they were building correctly anyway.
However, if anyone can do the above, I'll be happy to help them get
set up to push an 'info' branch to gitbuild.git
(http://repo.or.cz/w/git/gitbuild.git).
How often would you want the info pages rebuilt? Just the versions
which Junio tags? Or would you only want them built from one branch
(e.g. maint)?
Mike
^ permalink raw reply
* Re: request for pre-generated git.info pages
From: Miklos Vajna @ 2008-10-30 9:33 UTC (permalink / raw)
To: Mike Ralphson; +Cc: SLONIK.AZ, Git Mailing List, Junio C Hamano, Jeff King
In-Reply-To: <e2b179460810300206g79e06c63m2060092fa654b18b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
On Thu, Oct 30, 2008 at 09:06:35AM +0000, Mike Ralphson <mike.ralphson@gmail.com> wrote:
> How often would you want the info pages rebuilt? Just the versions
> which Junio tags? Or would you only want them built from one branch
> (e.g. maint)?
Probably it could be done in a similar way to the html and the man pages
(each time master is updated + for tags).
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [StGit PATCH 2/3] stgit.el: Added numeric prefix argument to push and pop commands.
From: David Kågedal @ 2008-10-30 9:52 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
In-Reply-To: <20081030095221.10290.58637.stgit@krank>
By using a numerical prefix (or simply C-u) it is possible to push or
pop more than one patch.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
contrib/stgit.el | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index e6b7d70..9907952 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -276,16 +276,19 @@ Commands:
(stgit-capture-output nil (stgit-run "uncommit" "-n" (number-to-string arg)))
(stgit-refresh))
-(defun stgit-push-next ()
- "Push the first unapplied patch"
- (interactive)
- (stgit-capture-output nil (stgit-run "push"))
+(defun stgit-push-next (npatches)
+ "Push the first unapplied patch.
+With numeric prefix argument, push that many patches."
+ (interactive "p")
+ (stgit-capture-output nil (stgit-run "push" "-n"
+ (number-to-string npatches)))
(stgit-refresh))
-(defun stgit-pop-next ()
- "Pop the topmost applied patch"
- (interactive)
- (stgit-capture-output nil (stgit-run "pop"))
+(defun stgit-pop-next (npatches)
+ "Pop the topmost applied patch.
+With numeric prefix argument, pop that many patches."
+ (interactive "p")
+ (stgit-capture-output nil (stgit-run "pop" "-n" (number-to-string npatches)))
(stgit-refresh))
(defun stgit-applied-at-point ()
^ permalink raw reply related
* [StGit PATCH 3/3] stgit.el: Adapt to new output from stg series.
From: David Kågedal @ 2008-10-30 9:52 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
In-Reply-To: <20081030095221.10290.58637.stgit@krank>
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
contrib/stgit.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index 9907952..d0f19c3 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -131,7 +131,8 @@ Argument DIR is the repository path."
(when (memq patchsym stgit-marked-patches)
(replace-match "*" nil nil nil 2)
(setq marked (cons patchsym marked)))))
- ((looking-at "stg series: Branch \".*\" not initialised")
+ ((or (looking-at "stg series: Branch \".*\" not initialised")
+ (looking-at "stg series: .*: branch not initialized"))
(forward-line 1)
(insert "Run M-x stgit-init to initialise")))
(forward-line 1))
^ permalink raw reply related
* [StGit PATCH 0/3] stgit.el patches
From: David Kågedal @ 2008-10-30 9:52 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
These three patches updates stgit.el. They don't depend on each other
and can be applied independently.
---
David Kågedal (3):
stgit.el: Adapt to new output from stg series.
stgit.el: Added numeric prefix argument to push and pop commands.
stgit.el: Added undo command
contrib/stgit.el | 36 ++++++++++++++++++++++++++----------
1 files changed, 26 insertions(+), 10 deletions(-)
--
Signature
^ permalink raw reply
* [StGit PATCH 1/3] stgit.el: Added undo command
From: David Kågedal @ 2008-10-30 9:52 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
In-Reply-To: <20081030095221.10290.58637.stgit@krank>
Bound it to the two standard bindings C-/ and C-_.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
---
contrib/stgit.el | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index aafefaf..e6b7d70 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -165,7 +165,9 @@ Argument DIR is the repository path."
(define-key stgit-mode-map "P" 'stgit-push-or-pop)
(define-key stgit-mode-map "G" 'stgit-goto)
(define-key stgit-mode-map "=" 'stgit-show)
- (define-key stgit-mode-map "D" 'stgit-delete))
+ (define-key stgit-mode-map "D" 'stgit-delete)
+ (define-key stgit-mode-map [(control ?/)] 'stgit-undo)
+ (define-key stgit-mode-map "\C-_" 'stgit-undo))
(defun stgit-mode ()
"Major mode for interacting with StGit.
@@ -408,4 +410,14 @@ Commands:
(interactive)
(describe-function 'stgit-mode))
+(defun stgit-undo (&optional arg)
+ "Run stg undo.
+With prefix argument, run it with the --hard flag."
+ (interactive "P")
+ (stgit-capture-output nil
+ (if arg
+ (stgit-run "undo" "--hard")
+ (stgit-run "undo")))
+ (stgit-refresh))
+
(provide 'stgit)
^ permalink raw reply related
* [PATCH] asciidoc: add minor workaround to add an empty line after code blocks
From: Jonas Fonseca @ 2008-10-30 10:45 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Junio C Hamano, git
In-Reply-To: <87od13ujm4.fsf@iki.fi>
Insert an empty <simpara> in manpages after code blocks to force and
empty line.
The problem can be seen on the manpage for the git tutorial, where an
example command and the following paragraph is printed with no empty
line between them:
First, note that you can get documentation for a command such as git
log --graph with:
$ man git-log
It is a good idea to introduce yourself to git [...]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/asciidoc.conf | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
Teemu Likonen <tlikonen@iki.fi> wrote Thu, Oct 30, 2008:
> In case someone is interested there is still a minor flaw that an
> example command and the following paragraph is printed with no empty
> line between them. Like in the beginning of "git help tutorial", for
> example:
>
> First, note that you can get documentation for a command such as git
> log --graph with:
>
> $ man git-log
> It is a good idea to introduce yourself to git [...]
>
> It would be nicer if there was empty line after "$ man git-log". I can't
> remember if this is new issue or not. This applies only to man pages; in
> html pages there are nice boxes around example commands and equal
> spacing before and after them.
This is an old issue reported by Theodore Ts'o and fixed partially in
commit 63c97ce228f2d2697a8ed954a9592dfb5f286338 for the URL section of
the fetch/pull/push manpages. I have fixed this in tig using an
approach similar to the attached. Simple and clean, but only tested
with docbook-xsl version 1.72 so I have made it conditional.
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 40d43b7..2da867d 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -40,6 +40,26 @@ endif::doctype-manpage[]
</literallayout>
{title#}</example>
endif::docbook-xsl-172[]
+
+ifdef::docbook-xsl-172[]
+ifdef::doctype-manpage[]
+# The following two small workarounds insert a simple paragraph after screen
+[listingblock]
+<example><title>{title}</title>
+<screen>
+|
+</screen><simpara></simpara>
+{title#}</example>
+
+[verseblock]
+<formalpara{id? id="{id}"}><title>{title}</title><para>
+{title%}<literallayout{id? id="{id}"}>
+{title#}<literallayout>
+|
+</literallayout><simpara></simpara>
+{title#}</para></formalpara>
+endif::doctype-manpage[]
+endif::docbook-xsl-172[]
endif::backend-docbook[]
ifdef::doctype-manpage[]
--
1.6.0.3.756.gb776d.dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [JGIT RFC PATCH 3/3] Rate limit warnings spewed by RepositoryTestCase.recursiveDelete
From: Jonas Fonseca @ 2008-10-30 10:46 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200810240110.21755.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote Fri, Oct 24, 2008:
> onsdagen den 22 oktober 2008 10.34.20 skrev Jonas Fonseca:
> > On Windows XP / NTFS / NetBeans 6.1 / Java 5 a lot of warnings are
> > printed. In most cases the path is in fact deleted and it seems to
> > just be a timing bug or something Windows or NTFS specific.
>
> The problem is actually flaws in the unit tests and in the supporting
> RepositoryTestCase. I think I'll fix that instead.
Thanks. Any progress on this? Can I help in any way?
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Stefan Karpinski @ 2008-10-30 10:55 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net>
These proposed changes look great.
On Wed, Oct 29, 2008 at 8:48 PM, Sam Vilain <sam@vilain.net> wrote:
> + * 'git unstage' would do what 'git reset --' does now
Would it make sense to deprecate using "git reset --" for this then?
It's always seemed confusing to me to have such disparate
functionality in the reset command.
> + * 'git export' command that does what
> + 'git archive --format=tar --prefix=dir | tar x' does now
It would be nice if the "git export" command could "checkout" a
non-repo copy of a remote repo at a specific version. This would be as
simple as calling archive on the remote size and then unarchiving it
locally. But would of course take care of all the plumbing.
(Sorry for the resend, Sam.)
^ permalink raw reply
* [PATCH 1/2] Add --verbose|-v to test-chmtime
From: Alex Riesen @ 2008-10-30 11:26 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano, René Scharfe
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
This allows us replace perl when getting the mtime of a file because
of time zone conversions, though at the moment only one platform which
does this has been identified: Cygwin when used with ActiveState Perl
(as usual).
The output format is:
<mtime1> TAB <filename1> <LF>
<mtime2> TAB <filename2> <LF>
...
which, if only mtime is needed can be parsed with cut(1):
test-chmtime -v +0 filename1 | cut -f 1
Also, the change adds a description of programs features, with examples.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
test-chmtime.c | 91 +++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 70 insertions(+), 21 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-verbose-v-to-test-chmtime.patch --]
[-- Type: text/x-diff; name=0001-Add-verbose-v-to-test-chmtime.patch, Size: 3995 bytes --]
From a59f17013cc54112d0bd11550b273baa6e312776 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 30 Oct 2008 10:00:29 +0100
Subject: [PATCH 1/2] Add --verbose|-v to test-chmtime
This allows us replace perl when getting the mtime of a file because
of time zone conversions, though at the moment only one platform which
does this has been identified: Cygwin when used with ActiveState Perl
(as usual).
The output format is:
<mtime1> TAB <filename1> <LF>
<mtime2> TAB <filename2> <LF>
...
which, if only mtime is needed can be parsed with cut(1):
test-chmtime -v +0 filename1 | cut -f 1
Also, the change adds a description of programs features, with examples.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
test-chmtime.c | 91 +++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 70 insertions(+), 21 deletions(-)
diff --git a/test-chmtime.c b/test-chmtime.c
index 90da448..d5358cb 100644
--- a/test-chmtime.c
+++ b/test-chmtime.c
@@ -1,39 +1,83 @@
+/*
+ * This program can either change modification time of the given
+ * file(s) or just print it. The program does not change atime nor
+ * ctime (their values are explicitely preserved).
+ *
+ * The mtime can be changed to an absolute value:
+ *
+ * test-chmtime =<seconds> file...
+ *
+ * Relative to the current time as returned by time(3):
+ *
+ * test-chmtime =+<seconds> (or =-<seconds>) file...
+ *
+ * Or relative to the current mtime of the file:
+ *
+ * test-chmtime <seconds> file...
+ * test-chmtime +<seconds> (or -<seconds>) file...
+ *
+ * Examples:
+ *
+ * To just print the mtime use --verbose and set the file mtime offset to 0:
+ *
+ * test-chmtime -v +0 file
+ *
+ * To set the mtime to current time:
+ *
+ * test-chmtime =+0 file
+ *
+ */
#include "git-compat-util.h"
#include <utime.h>
-static const char usage_str[] = "(+|=|=+|=-|-)<seconds> <file>...";
+static const char usage_str[] = "-v|--verbose (+|=|=+|=-|-)<seconds> <file>...";
-int main(int argc, const char *argv[])
+static int timespec_arg(const char *arg, long int *set_time, int *set_eq)
{
- int i;
- int set_eq;
- long int set_time;
char *test;
- const char *timespec;
-
- if (argc < 3)
- goto usage;
-
- timespec = argv[1];
- set_eq = (*timespec == '=') ? 1 : 0;
- if (set_eq) {
+ const char *timespec = arg;
+ *set_eq = (*timespec == '=') ? 1 : 0;
+ if (*set_eq) {
timespec++;
if (*timespec == '+') {
- set_eq = 2; /* relative "in the future" */
+ *set_eq = 2; /* relative "in the future" */
timespec++;
}
}
- set_time = strtol(timespec, &test, 10);
+ *set_time = strtol(timespec, &test, 10);
if (*test) {
- fprintf(stderr, "Not a base-10 integer: %s\n", argv[1] + 1);
- goto usage;
+ fprintf(stderr, "Not a base-10 integer: %s\n", arg + 1);
+ return 0;
}
- if ((set_eq && set_time < 0) || set_eq == 2) {
+ if ((*set_eq && *set_time < 0) || *set_eq == 2) {
time_t now = time(NULL);
- set_time += now;
+ *set_time += now;
}
+ return 1;
+}
+
+int main(int argc, const char *argv[])
+{
+ static int verbose;
- for (i = 2; i < argc; i++) {
+ int i = 1;
+ /* no mtime change by default */
+ int set_eq = 0;
+ long int set_time = 0;
+
+ if (argc < 3)
+ goto usage;
+
+ if (strcmp(argv[i], "--verbose") == 0 || strcmp(argv[i], "-v") == 0) {
+ verbose = 1;
+ ++i;
+ }
+ if (timespec_arg(argv[i], &set_time, &set_eq))
+ ++i;
+ else
+ goto usage;
+
+ for (; i < argc; i++) {
struct stat sb;
struct utimbuf utb;
@@ -46,7 +90,12 @@ int main(int argc, const char *argv[])
utb.actime = sb.st_atime;
utb.modtime = set_eq ? set_time : sb.st_mtime + set_time;
- if (utime(argv[i], &utb) < 0) {
+ if (verbose) {
+ uintmax_t mtime = utb.modtime < 0 ? 0: utb.modtime;
+ printf("%"PRIuMAX"\t%s\n", mtime, argv[i]);
+ }
+
+ if (utb.modtime != sb.st_mtime && utime(argv[i], &utb) < 0) {
fprintf(stderr, "Failed to modify time on %s: %s\n",
argv[i], strerror(errno));
return -1;
--
1.6.0.3.552.g4ff73
^ permalink raw reply related
* [PATCH 2/2] Use test-chmtime -v instead of perl in t5000 to get mtime of a file
From: Alex Riesen @ 2008-10-30 11:27 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano, René Scharfe
[-- Attachment #1: Type: text/plain, Size: 235 bytes --]
The test was broken on admittedly broken combination of Windows, Cygwin,
and ActiveState Perl.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
t/t5000-tar-tree.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Use-test-chmtime-v-instead-of-perl-in-t5000-to-get.patch --]
[-- Type: text/x-diff; name=0002-Use-test-chmtime-v-instead-of-perl-in-t5000-to-get.patch, Size: 990 bytes --]
From 1013c1a2b51a183bd0f6059b2e1a1ed68b2173d5 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 30 Oct 2008 11:20:27 +0100
Subject: [PATCH 2/2] Use test-chmtime -v instead of perl in t5000 to get mtime of a file
The test was broken on admittedly broken combination of Windows, Cygwin,
and ActiveState Perl.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
---
t/t5000-tar-tree.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 0f27d73..c942c8b 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -90,7 +90,7 @@ test_expect_success \
'validate file modification time' \
'mkdir extract &&
"$TAR" xf b.tar -C extract a/a &&
- perl -e '\''print((stat("extract/a/a"))[9], "\n")'\'' >b.mtime &&
+ test-chmtime -v +0 extract/a/a |cut -f 1 >b.mtime &&
echo "1117231200" >expected.mtime &&
diff expected.mtime b.mtime'
--
1.6.0.3.552.g4ff73
^ permalink raw reply related
* Re: [StGit PATCH 1/3] stgit.el: Added undo command
From: Karl Hasselström @ 2008-10-30 11:57 UTC (permalink / raw)
To: David Kågedal; +Cc: catalin.marinas, git
In-Reply-To: <20081030095248.10290.81253.stgit@krank>
On 2008-10-30 10:52:48 +0100, David Kågedal wrote:
> Bound it to the two standard bindings C-/ and C-_.
> + (define-key stgit-mode-map [(control ?/)] 'stgit-undo)
> + (define-key stgit-mode-map "\C-_" 'stgit-undo))
Hmm, why do you spell control in two different ways?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: request for pre-generated git.info pages
From: Mike Ralphson @ 2008-10-30 12:01 UTC (permalink / raw)
To: SLONIK.AZ, Git Mailing List; +Cc: Junio C Hamano, Jeff King, Miklos Vajna
In-Reply-To: <e2b179460810300206g79e06c63m2060092fa654b18b@mail.gmail.com>
2008/10/30 Mike Ralphson <mike.ralphson@gmail.com>:
> Unfortunately I don't have a working asciidoc etc toolchain either
> (though I will take a look at getting it working on my central git box
> which is Linux based). As I'm not an emacs or Info user I probably
> wouldn't know if they were building correctly anyway.
The only machine at my disposal with a working Python installation
(and I'm afraid I don't feel inclined to install it anywhere else,
Python on AIX is painful, and obviously if I was a Python nut, I'd be
running mercurial anyway, right?) is my desktop cygwin installation.
At least there obtaining asciidoc was no problem, but I think I'm
stuck in some docbook2x dependency hell with lots of twisty turny
prerequisities, all alike.
Now deep in a dark cave with a sign saying "Can't locate
XML/Handler/SGMLSpl.pm in @INC", which is where my adventure ends.
Score 0/100.
So a volunteer would still be appreciated.
Mike
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Bill Lear @ 2008-10-30 12:04 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1225343538.10803.9.camel@maia.lan>
On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
>On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
>> We use git in a way that makes it desirable for us to only push/pull
>> to the same remote branch. So, if I'm in branch X, I want 'git push'
>> to push to origin/X, and 'git pull' to fetch into origin/X and then
>> merge into X from origin/X.
>>
>> In other words, we want git push/pull to behave in branches other than
>> master the same way it does when in master.
>>
>> I have discovered the '--track' option when creating a local branch,
>> and this appears to me to be the thing that gives us the desired
>> behavior.
>
>As things currently stand this is not achievable behaviour. The
>behaviour of 'git push' is to push all matching refs. If you are lucky
>this is what you intended, but it also pushes any changes to *other*
>branches that you have made.
>
>I have tabled a change proposal to make it work as you suggest in a
>separate thread.
Ok, now I'm confused. The ONLY thing I want to prevent is the
"crossing of streams" issue. If I am on branch X and issue 'git
push', I want X, and ONLY X, to be pushed to the remote repository's X
branch --- I don't care if other branches are pushed to their
respective remote branches, as long as they don't get merged to X.
So, are you saying that Santi was incorrect, and that in fact
the push will result in a merge of the branches?
Bill
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Bill Lear @ 2008-10-30 12:12 UTC (permalink / raw)
To: Sam Vilain, git
In-Reply-To: <18697.41702.241183.408377@lisa.zopyra.com>
On Thursday, October 30, 2008 at 06:04:54 (-0600) Bill Lear writes:
>On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
>>On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
>>> We use git in a way that makes it desirable for us to only push/pull
>>> to the same remote branch. So, if I'm in branch X, I want 'git push'
>>> to push to origin/X, and 'git pull' to fetch into origin/X and then
>>> merge into X from origin/X.
>>>
>>> In other words, we want git push/pull to behave in branches other than
>>> master the same way it does when in master.
>>>
>>> I have discovered the '--track' option when creating a local branch,
>>> and this appears to me to be the thing that gives us the desired
>>> behavior.
>>
>>As things currently stand this is not achievable behaviour. The
>>behaviour of 'git push' is to push all matching refs. If you are lucky
>>this is what you intended, but it also pushes any changes to *other*
>>branches that you have made.
>>
>>I have tabled a change proposal to make it work as you suggest in a
>>separate thread.
>
>Ok, now I'm confused. The ONLY thing I want to prevent is the
>"crossing of streams" issue. If I am on branch X and issue 'git
>push', I want X, and ONLY X, to be pushed to the remote repository's X
>branch --- I don't care if other branches are pushed to their
>respective remote branches, as long as they don't get merged to X.
Oh, and also the same thing for 'git pull' --- sorry to leave that out.
Bill
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Andreas Ericsson @ 2008-10-30 12:25 UTC (permalink / raw)
To: Bill Lear; +Cc: Sam Vilain, git
In-Reply-To: <18697.42140.459170.891195@lisa.zopyra.com>
Bill Lear wrote:
> On Thursday, October 30, 2008 at 06:04:54 (-0600) Bill Lear writes:
>> On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
>>> On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
>>>> We use git in a way that makes it desirable for us to only push/pull
>>>> to the same remote branch. So, if I'm in branch X, I want 'git push'
>>>> to push to origin/X, and 'git pull' to fetch into origin/X and then
>>>> merge into X from origin/X.
>>>>
>>>> In other words, we want git push/pull to behave in branches other than
>>>> master the same way it does when in master.
>>>>
>>>> I have discovered the '--track' option when creating a local branch,
>>>> and this appears to me to be the thing that gives us the desired
>>>> behavior.
>>> As things currently stand this is not achievable behaviour. The
>>> behaviour of 'git push' is to push all matching refs. If you are lucky
>>> this is what you intended, but it also pushes any changes to *other*
>>> branches that you have made.
>>>
>>> I have tabled a change proposal to make it work as you suggest in a
>>> separate thread.
>> Ok, now I'm confused. The ONLY thing I want to prevent is the
>> "crossing of streams" issue. If I am on branch X and issue 'git
>> push', I want X, and ONLY X, to be pushed to the remote repository's X
>> branch --- I don't care if other branches are pushed to their
>> respective remote branches, as long as they don't get merged to X.
>
> Oh, and also the same thing for 'git pull' --- sorry to leave that out.
>
This particular bikeshed was painted a long time ago, with the consensus
going in favour of "git push" pushing all *matching* refspecs.
To convince people, I think you need to either come up with arguments
nullifying all the arguments *for* pushing all matching refspecs along
with patches to make the default configurable, with your preferred way
as a default, and a nifty enough shorthand for pushing/fetching all
matching refspecs. For preference, they should be at least 3 separate
patches.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Santi Béjar @ 2008-10-30 12:41 UTC (permalink / raw)
To: Bill Lear; +Cc: Sam Vilain, git
In-Reply-To: <18697.41702.241183.408377@lisa.zopyra.com>
On Thu, Oct 30, 2008 at 1:04 PM, Bill Lear <rael@zopyra.com> wrote:
> On Wednesday, October 29, 2008 at 22:12:18 (-0700) Sam Vilain writes:
>>On Wed, 2008-10-29 at 09:23 -0600, Bill Lear wrote:
>>> We use git in a way that makes it desirable for us to only push/pull
>>> to the same remote branch. So, if I'm in branch X, I want 'git push'
>>> to push to origin/X, and 'git pull' to fetch into origin/X and then
>>> merge into X from origin/X.
>>>
>>> In other words, we want git push/pull to behave in branches other than
>>> master the same way it does when in master.
>>>
>>> I have discovered the '--track' option when creating a local branch,
>>> and this appears to me to be the thing that gives us the desired
>>> behavior.
>>
>>As things currently stand this is not achievable behaviour. The
>>behaviour of 'git push' is to push all matching refs. If you are lucky
>>this is what you intended, but it also pushes any changes to *other*
>>branches that you have made.
>>
>>I have tabled a change proposal to make it work as you suggest in a
>>separate thread.
>
> Ok, now I'm confused. The ONLY thing I want to prevent is the
> "crossing of streams" issue. If I am on branch X and issue 'git
> push', I want X, and ONLY X, to be pushed to the remote repository's X
> branch --- I don't care if other branches are pushed to their
> respective remote branches, as long as they don't get merged to X.
No branches will get merged in a push.
>
> So, are you saying that Santi was incorrect, and that in fact
> the push will result in a merge of the branches?
Sorry, I was (partly) incorrect because I was only talking about pull.
For push you can add a "push = HEAD" config to the remote and then the
"git push" will only push the current branch (with the corresponding
matching remote branch).
$ git config remote.origin.push HEAD
Strictly speaking when you push (with the default config or with the
above trick) you push matching branches (it doesn't matter what is the
branch.<remote>.merge). Currently there is no way to say "push to the
corresponding tracking branch"
Still I think this will work as you want (as long as your local and
remote branch have the same name):
$ git clone $url
$ cd path
$ git config remote.origin.push HEAD
$ git checkout -b branch origin/branch
$ work, commit,...
$ git push
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] asciidoc: add minor workaround to add an empty line after code blocks
From: Teemu Likonen @ 2008-10-30 12:56 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, git
In-Reply-To: <20081030104503.GA17131@diku.dk>
Jonas Fonseca (2008-10-30 11:45 +0100) wrote:
> Insert an empty <simpara> in manpages after code blocks to force and
> empty line.
> This is an old issue reported by Theodore Ts'o and fixed partially in
> commit 63c97ce228f2d2697a8ed954a9592dfb5f286338 for the URL section
> of the fetch/pull/push manpages. I have fixed this in tig using an
> approach similar to the attached. Simple and clean, but only tested
> with docbook-xsl version 1.72 so I have made it conditional.
Thanks. Your patch seems to work and code blocks look much nicer now. I
tested command-line "man" as well as Emacs' "M-x man" and "M-x woman".
I'm using docbook-xsl Debian package version 1.73.2.dfsg.1-4.
Another kind of formatting issue exists with some other example
commands, like in "git rebase" manpage, for example. Not that I care
that much, but here's an example. The asciidoc source (git-rebase.txt)
contains:
then the command
git rebase --onto topicA~5 topicA~3 topicA
would result in the removal of commits F and G:
In final manpage output it looks like this:
then the command
git rebase --onto topicA~5 topicA~3 topicA
would result in the removal of commits F and G:
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Pierre Habouzit @ 2008-10-30 13:24 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Sam Vilain
In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net>
[-- Attachment #1: Type: text/plain, Size: 3292 bytes --]
On Thu, Oct 30, 2008 at 03:48:05AM +0000, Sam Vilain wrote:
> +Add/rm/reset/checkout/revert
> +----------------------------
> +
> +Many find these confusing.
> +
> + * 'git stage' would do what 'git add' does now.
-> git stage -i/-p shall do what git add -i/-p does.
> +
> + * 'git unstage' would do what 'git reset --' does now
-> likely we need a git unstage -i/-p to interactively unstage some
bits.
* 'git track' would do what git add -N does now.
* 'git untrack' would do what 'git rm --cached' does now.
> + * 'git undo' would do what 'git checkout HEAD --' does now
I'm not really a fan of this one. Undo is too unspecific (I know at
least 2 people using that for git reset --hard HEAD~1 and 1 other for an
alias to git reset --hard HEAD@{1}).
I have no constructive proposal to replace it though, but I believe git
undo would cause lots of harm. Would it be for another command, it
wouldn't be a problem, but git undo *LOSES* information by design (the
local changes on a file), and it would override aliases that people
could have done on it. Choosing it has consequences.
> +Working with patches
> +--------------------
> +
> + * 'git send-email' should prompt for all SMTP-related information
> + about sending e-mail when it is running with no configuration.
> + Because these days /usr/lib/sendmail is rarely configured
> + correctly.
And when the user answer them, it should set them (a bit like zsh does
when it's run from the first time e.g.)
> +
> + * other git send-email functionality which has bitten people -
> + particularly building the recipient list - should prompt for
> + confirmation until configured to be automatic.
> +
* git-send-email should be either more interactive, or less: either
just use the damn configuration, or propose a mode where it spawns
an editor for each patch so that you can add further comments.
* git-send-email should be able to format-patches by himself (IOW
accept most of format-patch arguments and deal with the patch list
by himself, which is usable if the previous point is implemented).
> + * 'git am -3' the default; with global option to make it not the
> + default for those that prefer the speed of -2
> +
> +
> +Submodules
> +----------
> +
> + * submodules should be able to refer to symbolic ref names, svn
> + style - in the .gitmodules file. The actual commit used is still
> + recorded in the index.
> +
> + * when switching branches, if the checked out revision of a submodule
> + changes, then it should be switched as well
> +
> + * 'git submodule update' should be able to be triggered when
> + switching branches (but not be the default behaviour)
Actually on this one, I'd say that a submodule is either non initialized
(in which case we don't care) or it is. If it is, switching branches
should probably trigger a submodule update if the switch isn't possible
(because the dereferenced sha1 doesn't exists). Or alternatively it
should make the whole branch switch fail.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-filter-branch: Add an example on how to remove empty commits
From: Pierre Habouzit @ 2008-10-30 13:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Sverre Rabbelier
In-Reply-To: <1225326833-15210-1-git-send-email-pasky@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
On Thu, Oct 30, 2008 at 12:33:53AM +0000, Petr Baudis wrote:
> From: Sverre Rabbelier <srabbelier@gmail.com>
>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
> Documentation/git-filter-branch.txt | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
> index fed6de6..2565244 100644
> --- a/Documentation/git-filter-branch.txt
> +++ b/Documentation/git-filter-branch.txt
> @@ -246,6 +246,21 @@ git filter-branch --commit-filter '
> fi' HEAD
> ------------------------------------------------------------------------------
>
> +To remove commits that are empty (do not introduce any change):
> +
> +------------------------------------------------------------------------------
> +git rev-list HEAD | while read c; do [ -n "$(git diff-tree --root $c)" ] || echo $c; done > revs
> +
> +git filter-branch --commit-filter '
> + if grep -q "$GIT_COMMIT" '"$(pwd)/"revs';
> + then
> + skip_commit "$@";
> + else
> + git commit-tree "$@";
> + fi' HEAD
> +
> +------------------------------------------------------------------------------
Why not add an option to filter-branch that removes a commit if it's
empty ? It's quite useful, it helps the user concentrating on just
keeping what matches *his* criteriums, and not caring about the minor
details of cleansing the result.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Using the --track option when creating a branch
From: Samuel Tardieu @ 2008-10-30 13:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Bill Lear, git
In-Reply-To: <4909A7C4.30507@op5.se>
>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
Andreas> This particular bikeshed was painted a long time ago, with
Andreas> the consensus going in favour of "git push" pushing all
Andreas> *matching* refspecs.
I still don't understand why this is useful, especially when git push
already has a "--all" option.
I know that I've never had the intent to push all the refs without
thinking about it first. Most of the time, I intend to push only
the current branch I am in.
The current behaviour made me remove the branches I was not actively
on locally, because I would get errors from "git push" all the time
saying that I was not up-to-date in those branches.
Note that the "git pull" issue is completely different, as it merges
or fast forwards the current branch only.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ 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