* Re: Serious bug with pretty format strings & empty bodies?
From: Alex Riesen @ 2007-12-19 18:44 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com>
Jonathan del Strother, Wed, Dec 19, 2007 15:32:20 +0100:
> I'm struggling to come up with a minimal test case that confirms this,
> but I seem to be hitting a bug in the pretty string formatter when
> trying to print bodies of commits that don't have bodies.
I tried
$ git init
$ git rev-list --pretty=format:"%s%n%b" \
$(echo -n "Test" |git commit-tree $(git write-tree))
but it works. It is possible that the commit in question is created
with an older commit-tree code. Could you try
git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
(or any other problematic commit) and post its output here?
Or is the repo publised somewhere?
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Jakub Narebski @ 2007-12-19 18:47 UTC (permalink / raw)
To: Dana How; +Cc: Linus Torvalds, Johannes Schindelin, Alex Riesen, git
In-Reply-To: <56b7f5510712190921v4350384fx97ab4b89e481ed46@mail.gmail.com>
On Wednesday, 19 December 2007, Dana How wrote:
> On Dec 19, 2007 3:23 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> That said, does git-showrel solution proposed by Johannes Schindelin
>> in
>> Message-ID: <Pine.LNX.4.64.0712182250040.23902@racer.site>
>> http://permalink.gmane.org/gmane.comp.version-control.git/68840
>> work for you?
>>
>> Below version of git-showrel script which uses proposed
>> 'commit:./relpath' syntax (it could be improved, of course):
>>
>> cat> git-showrel <<\EOF
>> #!/bin/sh
>>
>> rel=$(git rev-parse --show-prefix 2>/dev/null)
>> git show $(echo "$@" | sed -e "s!:./!:${rel}!")
>>
>> EOF
>
> It's definitely true I could use this for now. In the long run
> (meaning after the feature freeze) I don't view this as adequate
> for 2 reasons:
> (1) I would like a consistent interpretation of commit:path
> wherever it is accepted; and
Of course this is only interim solution, after 1.5.4 is out, we are out
of feature freeze, and <path>:./<relpath> is in.
> (2) If a novice types bad arguments to git-showrel , they
> are probably going to be very confused by its error messages
> which are a response to a munged version of their command line.
Actually git-showrel should change only the _last_ argument, passing all
other unchanged to git-show. But this requires something more than
simplest script as above...
Unfortunately my shell script hackery is not up to the task ;-(
--
Jakub Narebski
Poland
^ permalink raw reply
* git svn dcommit -n rebuilds revmap w/ 1.5.4.rc0.1187.gc1e8d
From: Bill Priest @ 2007-12-19 19:04 UTC (permalink / raw)
To: git
All,
I had been experiencing commit slow downs (> 15
seconds) so I decided to test it out on 1.5.4.rc0. I
use committed a file and it too ~5 seconds which is
slower than it used to be but much better (I'll need
to do an apples to apples test to quantify it better;
e.g. check in the same file w/ a repository in the
same state). In the course of using 1.5.4.rc0 I did a
git svn dcommit -n and observed the following:
> git svn dcommit -n
Rebuilding
.git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
...
r2918 = 992aa04a75fffdbdb65bae815905f96d5e3ef6bd
r2920 = e68e7f5aead05fc9e7a151e95f43b8283b0ed670
Done rebuilding
.git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
Committing to
svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
...
diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
0bbb656391f5a888d07c98ccce01a4c753ef4997
> git svn dcommit -n
Committing to
svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
...
diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
0bbb656391f5a888d07c98ccce01a4c753ef4997
> git --version
git version 1.5.4.rc0.1187.gc1e8d
Notice the Rebuilding doesn't seem to be honoring the
-n "dry run" switch.
I'm not sure of the implications. Is this something
that I should worry about the .revmap being out of
sync w/ what has actually been dcommit'ed?
Bill
PS. The new path relative status is nice.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Junio C Hamano @ 2007-12-19 19:57 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andreas Ericsson, git
In-Reply-To: <20071218114949.711ba447@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Merijn, discarding the earlier patch I did to configure it out for
>> HP-UX, does the following patch based on Andreas's idea work for you?
>
> Probably not:
>
> HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
>
> /usr/include 103 > grep -r POSIX_VERSION *
> sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
> sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
> sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
> sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
> sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
>
> and the two 11.23 do have select.h
Does that prove anything? unistd.h seem to define _POSIX_VERSION to
various values but we do not see surrounding "#ifdef WE_DO_NOT_KNOW"
from the grep output above unfortunately.
If the folllowing actually works I think that is the cleanest fix for
this issue (note that I added defined(_POSIX_VERSION) there just to be
safe if it is not defined at all).
git-compat-util.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 79eb10e..68a580f 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -68,7 +68,9 @@
#include <sys/poll.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
+#if defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L
#include <sys/select.h>
+#endif
#include <assert.h>
#include <regex.h>
#include <netinet/in.h>
^ permalink raw reply related
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-19 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vr6hiv4ny.fsf@gitster.siamese.dyndns.org>
On Wed, 19 Dec 2007 11:57:21 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > ...
> >> Merijn, discarding the earlier patch I did to configure it out for
> >> HP-UX, does the following patch based on Andreas's idea work for you?
> >
> > Probably not:
> >
> > HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
> >
> > /usr/include 103 > grep -r POSIX_VERSION *
> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
> > sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> > sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> > sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
> >
> > and the two 11.23 do have select.h
>
> Does that prove anything? unistd.h seem to define _POSIX_VERSION to
> various values but we do not see surrounding "#ifdef WE_DO_NOT_KNOW"
> from the grep output above unfortunately.
What I tried to demonstrate is that I have no clue about the actual value
of this define, and if values like 88, 90, and 93 (7, 102, and 103) do
have any relation with the higher value of 200112L that you use.
Also because these are the *only* _POSIX_VERSION defines in the entire
include tree, and 11.23 does have a select.h, which makes the patch below
to be not OK on 11.23. I'm not stating that HP follows the rules in any
correct way, but if this is to be sure that select.h gets included if the
OS supports it, it will fail.
> If the folllowing actually works I think that is the cleanest fix for
> this issue (note that I added defined(_POSIX_VERSION) there just to be
> safe if it is not defined at all).
>
> git-compat-util.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 79eb10e..68a580f 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -68,7 +68,9 @@
> #include <sys/poll.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> +#if defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112L
> #include <sys/select.h>
> +#endif
> #include <assert.h>
> #include <regex.h>
> #include <netinet/in.h>
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: git-svn and migration
From: Miklos Vajna @ 2007-12-19 20:23 UTC (permalink / raw)
To: Steven Walter; +Cc: Nigel Magnay, git
In-Reply-To: <20071219175447.GB15898@dervierte>
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Wed, Dec 19, 2007 at 12:54:47PM -0500, Steven Walter <stevenrwalter@gmail.com> wrote:
> Using a central git repo that is kept uptodate with svn is the approach
> I've used. git-svn isn't especially keen on this mode of operation,
> however. After every fetch, you have to reset refs/remotes/trunk to
> origin/master, which it turn puts .git/svn out of date (you can blow it
> away and run "git svn fetch" to regenerate it).
an other problem is that you probably want to have a bare repo while
git-svn needs a working dir. a possible solution:
http://blogs.frugalware.org/vmiklos/2007/12/09/p320
(it works for me fine, but maybe there are problems with it so use with
care :) )
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
From: Sean @ 2007-12-19 20:37 UTC (permalink / raw)
To: Haavard Skinnemoen; +Cc: git
In-Reply-To: <20071219150734.50b1f847@dhcp-252-066.norway.atmel.com>
On Wed, 19 Dec 2007 15:07:34 +0100
Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:
> On Wed, 19 Dec 2007 12:40:08 +0100
> Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:
>
> > Btw, the funny thing is that, looking at my shell history, I think I
> > actually did the right thing when committing your patches:
> >
> > git commit -s --author 'Remy Bohmer <linux@bohmer.net>'
> > git commit -s --author 'Chip Coldwell <coldwell@frank.harvard.edu>'
> >
> > But for some reason only your names stuck, not your e-mail addresses...
>
> It just happened again. Seems like if git-rebase hits a conflict, and I
> just do "git-rebase --continue" after resolving it (and updating the
> index), the original author's name is used, but not his e-mail address.
>
> Looks like a bug in git-rebase...?
>
Hi Haavard,
Can't reproduce this here with the version of Git you're using (1.5.3.4).
Can you figure out a small test case that shows the problem? Perhaps the
problem only shows up in your environment or with your particular config
file settings.
Regards,
Sean
P.S. Trimmed CC list.
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Junio C Hamano @ 2007-12-19 20:45 UTC (permalink / raw)
To: Dana How
Cc: Junio C Hamano, Linus Torvalds, Jakub Narebski, Alex Riesen, git,
Johannes Schindelin
In-Reply-To: <56b7f5510712181430w798d4a65x20a24f061c5d0eb6@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> How about this:
> <tree-ish>:./path -> NEW: relative
I think making "<tree>:./" mean "replace ./ with the current prefix and
retry the usual expansion" is relatively confusion free. You have to
work hard to confuse yourself:
d=$(git rev-parse --verify HEAD:Documentation)
git rev-parse "$d":./howto ;# would not work
cd Documentation && git rev-parse "$d":./howto ;# would work
> <tree-ish>:../path -> NEW: relative
I would rather avoid up (../) processing if we can, but making "<tree>:"
immediately followed by 1 or more "../" mean "take the current prefix,
strip away the same number of trailing directory components as we have
"../" there, and tuck the remainder in front of the path before trying
the usual expansion" would be a natural and relatively confusion free
extension of the above. I think I can live with that, too.
> <tree-ish>:?pattern -> NEW: same as next (current :/ )
I'd prefer keeping :? (or some other unlikely-in-path letter other than
'?') as a special extension introducer character, i.e. leaving the door
open to:
<tree>:?(magic)parameter
whose semantics is to be defined later, depending on "magic".
Similarly, we could do the same for
:?(magic)parameter
> <tree-ish>:/pattern -> unchanged (sha1_name_oneline IIRC)
I do not think this is oneline. "<commit>:/pattern" could be a natural
extension to the current ":/pattern" that instructs "dig from only this
commit, not all refs, and find a commit with the oneline," but I do not
think it is a good idea. It is too similar to "locate this tree entry
from the given tree" syntax.
> <tree-ish>:path -> unchanged: absolute
Absolutely ;-)
^ permalink raw reply
* git-svn and migration
From: Nigel Magnay @ 2007-12-19 20:47 UTC (permalink / raw)
To: git
In-Reply-To: <320075ff0712191246r46cd76f7r1d8edc1adf35ae57@mail.gmail.com>
I was prepared to put up with it not being a bare repository (asides
the extra /.git/ in the URL it's pretty much the same).
On the git host I'd set refs/heads/trunk to be
ref: refs/remotes/svn/trunk
And I'm hoping that a cron of git svn fetch ; git-update-server-info
will do the trick. It appeared to keep it in sync when I fetch
downstream. I don't know if I'm being naive though expecting that to
work as I don't grok all that git-svn needs to work properly - but I'm
working on it ;-)
My current plan is for developers to push/pull to git to share amongst
the git-devs, and to push to svn when wanting to share with everyone
else..
[svn user] ---(ci/co)--->[svn] --pull--> [git]
^ ^
| |
push push/pull
| |
---[git user]----
On Dec 19, 2007 8:23 PM, Miklos Vajna < vmiklos@frugalware.org> wrote:
> On Wed, Dec 19, 2007 at 12:54:47PM -0500, Steven Walter < stevenrwalter@gmail.com> wrote:
> > Using a central git repo that is kept uptodate with svn is the approach
> > I've used. git-svn isn't especially keen on this mode of operation,
> > however. After every fetch, you have to reset refs/remotes/trunk to
> > origin/master, which it turn puts .git/svn out of date (you can blow it
> > away and run "git svn fetch" to regenerate it).
>
> an other problem is that you probably want to have a bare repo while
> git-svn needs a working dir. a possible solution:
>
> http://blogs.frugalware.org/vmiklos/2007/12/09/p320
>
> (it works for me fine, but maybe there are problems with it so use with
> care :) )
>
> - VMiklos
>
^ permalink raw reply
* Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
From: Haavard Skinnemoen @ 2007-12-19 21:02 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP13613FE244FF93DC2BF613AE5C0@CEZ.ICE>
On Wed, 19 Dec 2007 15:37:45 -0500
Sean <seanlkml@sympatico.ca> wrote:
> Can't reproduce this here with the version of Git you're using
> (1.5.3.4). Can you figure out a small test case that shows the
> problem? Perhaps the problem only shows up in your environment or
> with your particular config file settings.
Ah...seems like it only happens when I use git-rebase --interactive...
Test case:
1. Start with two branches pointing to the same commit
2. Modify the same file on both branches in conflicting ways.
3. Commit using a different author than the default.
4. Use git rebase -i to rebase one of the branches on top of the other
5. Resolve the conflict, update the index and run git rebase --continue
The last commit is now attributed to the correct name, but the default
e-mail address (from git-config.)
Just tested it with git 1.5.3.6 on a different computer.
> P.S. Trimmed CC list.
Thanks :-)
Haavard
^ permalink raw reply
* Re: git-svn and migration
From: Seth Falcon @ 2007-12-19 21:14 UTC (permalink / raw)
To: Nigel Magnay; +Cc: git
In-Reply-To: <320075ff0712191247m132ecd95o46a7778d8bd4f42b@mail.gmail.com>
"Nigel Magnay" <nigel.magnay@gmail.com> writes:
> I was prepared to put up with it not being a bare repository (asides
> the extra /.git/ in the URL it's pretty much the same).
>
> On the git host I'd set refs/heads/trunk to be
> ref: refs/remotes/svn/trunk
>
> And I'm hoping that a cron of git svn fetch ; git-update-server-info
> will do the trick. It appeared to keep it in sync when I fetch
> downstream. I don't know if I'm being naive though expecting that to
> work as I don't grok all that git-svn needs to work properly - but I'm
> working on it ;-)
>
> My current plan is for developers to push/pull to git to share amongst
> the git-devs, and to push to svn when wanting to share with everyone
> else..
>
> [svn user] ---(ci/co)--->[svn] --pull--> [git]
> ^ ^
> | |
> push push/pull
> | |
> ---[git user]----
I suspect having the git users push/fetch only from svn
would be more reliable. Won't there be problems if git users
do merges and push to the git repo?
Also, seems like it makes the transition more complicateds for git
users since they have to figure out git-svn _and_ the git push/pull.
Perhaps avoid the central git repo until everyone is on git. Then
people have to learn not to use git-svn and to use push/pull instead.
My $0.02
+ seth
--
Seth Falcon | seth@userprimary.net | blog: http://userprimary.net/user/
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Junio C Hamano @ 2007-12-19 21:31 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Andreas Ericsson, git
In-Reply-To: <20071219211226.41920430@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> On Wed, 19 Dec 2007 11:57:21 -0800, Junio C Hamano <gitster@pobox.com> wrote:
>
>> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>>
>> > On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
>> > ...
>> >> Merijn, discarding the earlier patch I did to configure it out for
>> >> HP-UX, does the following patch based on Andreas's idea work for you?
>> >
>> > Probably not:
>> >
>> > HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
>> >
>> > /usr/include 103 > grep -r POSIX_VERSION *
>> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
>> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
>> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
>> > sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
>> > sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
>> > sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
>> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
>> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
>> >
>> > and the two 11.23 do have select.h
>>
>> Does that prove anything? unistd.h seem to define _POSIX_VERSION to
>> various values but we do not see surrounding "#ifdef WE_DO_NOT_KNOW"
>> from the grep output above unfortunately.
>
> What I tried to demonstrate is that I have no clue about the actual value
> of this define, and if values like 88, 90, and 93 (7, 102, and 103) do
> have any relation with the higher value of 200112L that you use.
>
> Also because these are the *only* _POSIX_VERSION defines in the entire
> include tree, and 11.23 does have a select.h, which makes the patch below
> to be not OK on 11.23. I'm not stating that HP follows the rules in any
> correct way, but if this is to be sure that select.h gets included if the
> OS supports it, it will fail.
>
>> If the folllowing actually works I think that is the cleanest fix for
>> this issue (note that I added defined(_POSIX_VERSION) there just to be
>> safe if it is not defined at all).
But your grep did not catch their definition of _POSIX1_VERSION_$YEAR
which are used to define the actual value of _POSIX_VERSION.
^ permalink raw reply
* [PATCH] Fix interactive rebase to preserve author email address
From: Sean @ 2007-12-19 21:34 UTC (permalink / raw)
To: Haavard Skinnemoen; +Cc: git
In-Reply-To: <20071219220223.7c5b3887@siona>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This simple typo fix should hopefully make it work for you Haavard.
Cheers,
Sean
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index cd7e43f..7153ac7 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -371,7 +371,7 @@ do
. "$DOTEST"/author-script && {
test ! -f "$DOTEST"/amend || git reset --soft HEAD^
} &&
- export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
+ export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
git commit -F "$DOTEST"/message -e
require_clean_work_tree
--
1.5.4.rc0.73.gce85b
^ permalink raw reply related
* Re: [PATCH] Fix interactive rebase to preserve author email address
From: Johannes Schindelin @ 2007-12-19 22:11 UTC (permalink / raw)
To: Sean; +Cc: Haavard Skinnemoen, git
In-Reply-To: <BAYC1-PASMTP022BE21217030117EF2156AE5C0@CEZ.ICE>
Hi,
On Wed, 19 Dec 2007, Sean wrote:
> - export GIT_AUTHOR_NAME GIT_AUTHOR_NAME GIT_AUTHOR_DATE &&
> + export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE &&
Ouch. My mistake (from July 8).
ACK.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix interactive rebase to preserve author email address
From: Haavard Skinnemoen @ 2007-12-19 22:11 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP022BE21217030117EF2156AE5C0@CEZ.ICE>
On Wed, 19 Dec 2007 16:34:27 -0500
Sean <seanlkml@sympatico.ca> wrote:
> This simple typo fix should hopefully make it work for you Haavard.
It does indeed. Thanks!
Haavard
^ permalink raw reply
* Git-to-svn convert
From: Thomas Harning @ 2007-12-19 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Is there a reasonable way to convert a Git project to Subversion...
Yeah, I know, blasphemy :-P... but I worked on a project in Git and my
boss wants me to put it into Subversion.
git-svn looks to be the tool for this.. however I had some non-linear
dev, which doesn't look like it'd commit (In the past I think I tried
this and it failed to deal w/ a branch-and-merge...).
Example of what I mean...:
a - b -
`c'
As to how to pull the repository into subversion.. how would I do that?
git-svn init ?
^ permalink raw reply
* [StGit PATCH 0/2] Make new infrastructure subdirectory safe
From: Karl Hasselström @ 2007-12-19 22:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071218092419.GA16029@diana.vm.bytemark.co.uk>
---
Karl Hasselström (2):
Make "stg goto" subdirectory safe
Test that "stg goto" can be called from a subdirectory
stgit/lib/git.py | 5 ++--
stgit/run.py | 9 +++++--
t/t2800-goto-subdir.sh | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 68 insertions(+), 5 deletions(-)
create mode 100755 t/t2800-goto-subdir.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [StGit PATCH 1/2] Test that "stg goto" can be called from a subdirectory
From: Karl Hasselström @ 2007-12-19 22:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221848.29455.50676.stgit@yoghurt>
It currently can't; therefore, the tests are marked as known failures.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t2800-goto-subdir.sh | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
create mode 100755 t/t2800-goto-subdir.sh
diff --git a/t/t2800-goto-subdir.sh b/t/t2800-goto-subdir.sh
new file mode 100755
index 0000000..9f3ab26
--- /dev/null
+++ b/t/t2800-goto-subdir.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+
+test_description='Run "stg goto" in a subdirectory'
+
+. ./test-lib.sh
+
+test_expect_success 'Initialize StGit stack' '
+ stg init &&
+ echo expected1.txt >> .git/info/exclude &&
+ echo expected2.txt >> .git/info/exclude &&
+ echo actual.txt >> .git/info/exclude &&
+ mkdir foo &&
+ for i in 1 2 3; do
+ echo foo$i >> foo/bar &&
+ stg new p$i -m p$i &&
+ git add foo/bar &&
+ stg refresh
+ done
+'
+
+cat > expected1.txt <<EOF
+foo1
+EOF
+cat > expected2.txt <<EOF
+bar
+EOF
+test_expect_failure 'Goto in subdirectory (just pop)' '
+ (cd foo && stg goto p1) &&
+ cat foo/bar > actual.txt &&
+ diff -u expected1.txt actual.txt &&
+ ls foo > actual.txt &&
+ diff -u expected2.txt actual.txt
+'
+
+test_expect_success 'Prepare conflicting goto' '
+ stg delete p2
+'
+
+cat > expected1.txt <<EOF
+foo1
+<<<<<<< current:foo/bar
+=======
+foo2
+foo3
+>>>>>>> patched:foo/bar
+EOF
+cat > expected2.txt <<EOF
+bar
+EOF
+test_expect_failure 'Goto in subdirectory (conflicting push)' '
+ (cd foo && stg goto p3) ;
+ [ $? -eq 3 ] &&
+ cat foo/bar > actual.txt &&
+ diff -u expected1.txt actual.txt &&
+ ls foo > actual.txt &&
+ diff -u expected2.txt actual.txt
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 2/2] Make "stg goto" subdirectory safe
From: Karl Hasselström @ 2007-12-19 22:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221848.29455.50676.stgit@yoghurt>
This is not specific to "stg goto" -- it affects all commands that use
the new infrastructure. (But of those, only goto and coalesce were
subdirectory unsafe.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-12-18 10:24:19 +0100, Karl Hasselström wrote:
> On 2007-12-18 09:11:00 +0000, Catalin Marinas wrote:
>
> > On 17/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> >
> > > Be careful about merging past the "goto" patch -- I'm pretty
> > > sure it breaks when called from a subdirectory, and I don't have
> > > time to fix that right now. (It should be a clean fix, though --
> > > just adjust the cwd for precisely those git subprocesses that
> > > need it, which is very few. I think.)
> >
> > Why not just change the cwd when the command starts and it should
> > be safe for all the git subprocesses.
>
> It doesn't feel very clean to require the caller of some unspecified
> subset of git calls to remember to set the correct piece of global
> state.
>
> And the correct solution should really be very simple, since it's
> precisely the worktree operations (specifically, the subset thereof
> that have to operate on the whole tree) that require setting cwd.
> And those are very clearly separated out from the rest in the new
> infrastructure.
And here it is! Note that not counting the cwd support in run.py and
changing the test to expect success, I had to change just three lines
to fix this problem for _all_ "new infrastructure" commands. And no
unintended side effects, since the cwd is changed only where it's
necessary.
stgit/lib/git.py | 5 +++--
stgit/run.py | 9 ++++++---
t/t2800-goto-subdir.sh | 4 ++--
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index 6aba966..118c9b2 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -344,6 +344,7 @@ class Worktree(object):
def __init__(self, directory):
self.__directory = directory
env = property(lambda self: { 'GIT_WORK_TREE': self.__directory })
+ directory = property(lambda self: self.__directory)
class CheckoutException(exception.StgException):
pass
@@ -364,7 +365,7 @@ class IndexAndWorktree(RunWithEnv):
self.run(['git', 'read-tree', '-u', '-m',
'--exclude-per-directory=.gitignore',
old_tree.sha1, new_tree.sha1]
- ).discard_output()
+ ).cwd(self.__worktree.directory).discard_output()
except run.RunException:
raise CheckoutException('Index/workdir dirty')
def merge(self, base, ours, theirs):
@@ -377,7 +378,7 @@ class IndexAndWorktree(RunWithEnv):
env = { 'GITHEAD_%s' % base.sha1: 'ancestor',
'GITHEAD_%s' % ours.sha1: 'current',
'GITHEAD_%s' % theirs.sha1: 'patched'}
- ).discard_output()
+ ).cwd(self.__worktree.directory).discard_output()
except run.RunException, e:
raise MergeException('Index/worktree dirty')
def changed_files(self):
diff --git a/stgit/run.py b/stgit/run.py
index 78537db..77f2e65 100644
--- a/stgit/run.py
+++ b/stgit/run.py
@@ -42,7 +42,7 @@ class Run:
if type(c) != str:
raise Exception, 'Bad command: %r' % (cmd,)
self.__good_retvals = [0]
- self.__env = None
+ self.__env = self.__cwd = None
self.__indata = None
self.__discard_stderr = False
def __log_start(self):
@@ -67,7 +67,7 @@ class Run:
"""Run with captured IO."""
self.__log_start()
try:
- p = subprocess.Popen(self.__cmd, env = self.__env,
+ p = subprocess.Popen(self.__cmd, env = self.__env, cwd = self.__cwd,
stdin = subprocess.PIPE,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE)
@@ -85,7 +85,7 @@ class Run:
assert self.__indata == None
self.__log_start()
try:
- p = subprocess.Popen(self.__cmd, env = self.__env)
+ p = subprocess.Popen(self.__cmd, env = self.__env, cwd = self.__cwd)
self.exitcode = p.wait()
except OSError, e:
raise self.exc('%s failed: %s' % (self.__cmd[0], e))
@@ -104,6 +104,9 @@ class Run:
self.__env = dict(os.environ)
self.__env.update(env)
return self
+ def cwd(self, cwd):
+ self.__cwd = cwd
+ return self
def raw_input(self, indata):
self.__indata = indata
return self
diff --git a/t/t2800-goto-subdir.sh b/t/t2800-goto-subdir.sh
index 9f3ab26..fcad7da 100755
--- a/t/t2800-goto-subdir.sh
+++ b/t/t2800-goto-subdir.sh
@@ -24,7 +24,7 @@ EOF
cat > expected2.txt <<EOF
bar
EOF
-test_expect_failure 'Goto in subdirectory (just pop)' '
+test_expect_success 'Goto in subdirectory (just pop)' '
(cd foo && stg goto p1) &&
cat foo/bar > actual.txt &&
diff -u expected1.txt actual.txt &&
@@ -47,7 +47,7 @@ EOF
cat > expected2.txt <<EOF
bar
EOF
-test_expect_failure 'Goto in subdirectory (conflicting push)' '
+test_expect_success 'Goto in subdirectory (conflicting push)' '
(cd foo && stg goto p3) ;
[ $? -eq 3 ] &&
cat foo/bar > actual.txt &&
^ permalink raw reply related
* Re: [StGit PATCH 0/2] Make new infrastructure subdirectory safe
From: Karl Hasselström @ 2007-12-19 22:28 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221848.29455.50676.stgit@yoghurt>
On 2007-12-19 23:19:23 +0100, Karl Hasselström wrote:
> Karl Hasselström (2):
> Make "stg goto" subdirectory safe
> Test that "stg goto" can be called from a subdirectory
I forgot to say, but this goes on top of kha/experimental. The test
makes use of the "return exit code 3 when there was conflicts" patch
to make sure that there was a conflict and not another error.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-19 22:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071219184457.GC3015@steel.home>
On Dec 19, 2007 6:44 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Could you try
>
> git cat-file 18d2480ab689b483ef1ebbdb3f7420904049ba0b
>
> (or any other problematic commit) and post its output here?
You mean git cat-file commit ... ?
I get the normal output, but the problematic commits don't show a
newline character at the end of the cat-file output.
> Or is the repo publised somewhere?
Afraid not - it's private code.
I'll try bisecting e52a5de tomorrow, see if that gets me anywhere.
^ permalink raw reply
* kha/safe updated
From: Karl Hasselström @ 2007-12-19 22:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, David Kågedal
In-Reply-To: <20071219221957.29455.27315.stgit@yoghurt>
On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
> And here it is!
And with that, I don't see any reason to not recommend that you pull
every patch I have. Which is:
The following changes since commit 5be69cd8d89bd89be31364e9c0fd9e947b6ef644:
Karl Hasselström (1):
Name the exit codes to improve legibility
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
David Kågedal (19):
Add an StGit mode for emacs
Emacs mode: Improve the output buffer state
Emacs mode: Bind n and p
Emacs mode: add stgit-repair
Emacs mode: added stgit-commit and stgit-uncommit
Emacs mode: Add stgit-edit command
Emacs mode: added fontification
Emacs mode: Added stgit-new
Check bottom and invariants
Remove the 'bottom' field
Remove the 'top' field
Split git.merge into two functions
Leave working dir and index alone after failed (conflicting) push
Added a test case to check what happens when push finds a conflict
Simplify merge_recursive
Use the output from merge-recursive to list conflicts
Ask git about unmerged files
Emacs mode: Add mark command
Emacs mode: coalesce command
Karl Hasselström (36):
Emacs mode: Show keybindings when user presses "h" or "?"
Emacs mode: Add an explanatory header
Emacs mode: Makefile for building stgit.el
Emacs mode: push/pop next patch, not patch at point
Emacs mode: Let "P" push or pop patch at point
Emacs mode: Bind "G" to "stg goto"
Emacs mode: show patches' short description
Write removed fields for backwards compatibility
Nicer conflict markers
Better error message if merge fails
Fix "stg resolved" to work with new conflict representation
Refactoring: pass more than one file to resolved()
We keep the different stages of a conflict in the index now
"stg status --reset" is not needed anymore
Remove "stg add"
Remove "stg rm"
Remove "stg cp"
Remove "stg resolved"
New StGit core infrastructure: repository operations
Write metadata files used by the old infrastructure
Upgrade older stacks to newest version
Let "stg clean" use the new infrastructure
Add "stg coalesce"
Let "stg applied" and "stg unapplied" use the new infrastructure
Teach the new infrastructure about the index and worktree
Let "stg clean" use the new transaction primitives
Let "stg goto" use the new infrastructure
Convert "stg uncommit" to the new infrastructure
New infrastructure: Make sure that the branch is initialized
Expose transaction abort function
stg coalesce: Support --file and --save-template
Set exit code to 3 on merge conflict
Convert "stg commit" to new infrastructure
Make "stg commit" fancier
Test that "stg goto" can be called from a subdirectory
Make "stg goto" subdirectory safe
Documentation/stg-cp.txt | 63 -------
Documentation/stg.txt | 2 -
Documentation/tutorial.txt | 31 ++--
contrib/Makefile | 19 ++
contrib/stgit-completion.bash | 4 +-
contrib/stgit.el | 377 +++++++++++++++++++++++++++++++++++++++
examples/gitconfig | 19 +--
setup.py | 2 +-
stgit/commands/add.py | 44 -----
stgit/commands/applied.py | 27 ++--
stgit/commands/clean.py | 49 ++----
stgit/commands/coalesce.py | 122 +++++++++++++
stgit/commands/commit.py | 111 ++++++++-----
stgit/commands/common.py | 39 ++---
stgit/commands/copy.py | 45 -----
stgit/commands/goto.py | 52 ++----
stgit/commands/pick.py | 2 +-
stgit/commands/resolved.py | 94 ----------
stgit/commands/rm.py | 48 -----
stgit/commands/status.py | 31 ++--
stgit/commands/sync.py | 1 -
stgit/commands/unapplied.py | 23 ++--
stgit/commands/uncommit.py | 81 ++++-----
stgit/config.py | 1 -
stgit/git.py | 75 +++++---
stgit/gitmergeonefile.py | 97 +----------
stgit/lib/__init__.py | 18 ++
stgit/lib/git.py | 388 +++++++++++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 176 +++++++++++++++++++
stgit/lib/stackupgrade.py | 98 +++++++++++
stgit/lib/transaction.py | 209 ++++++++++++++++++++++
stgit/main.py | 14 +-
stgit/run.py | 12 +-
stgit/stack.py | 156 ++++-------------
stgit/utils.py | 25 +++
t/t0002-status.sh | 15 +-
t/t1200-push-modified.sh | 2 +-
t/t1202-push-undo.sh | 6 +-
t/t1203-push-conflict.sh | 70 ++++++++
t/t1204-pop-keep.sh | 2 +-
t/t1205-push-subdir.sh | 8 +-
t/t1300-uncommit.sh | 16 +-
t/t1301-repair.sh | 2 +-
t/t1400-patch-history.sh | 4 +-
t/t1500-float.sh | 14 +-
t/t1600-delete-one.sh | 12 +-
t/t1601-delete-many.sh | 2 +-
t/t1700-goto-top.sh | 2 +-
t/t2000-sync.sh | 12 +-
t/t2100-pull-policy-fetch.sh | 4 +-
t/t2101-pull-policy-pull.sh | 4 +-
t/t2102-pull-policy-rebase.sh | 4 +-
t/t2300-refresh-subdir.sh | 2 +-
t/t2600-coalesce.sh | 31 ++++
t/t2800-goto-subdir.sh | 59 ++++++
55 files changed, 1959 insertions(+), 867 deletions(-)
delete mode 100644 Documentation/stg-cp.txt
create mode 100644 contrib/Makefile
create mode 100644 contrib/stgit.el
delete mode 100644 stgit/commands/add.py
create mode 100644 stgit/commands/coalesce.py
delete mode 100644 stgit/commands/copy.py
delete mode 100644 stgit/commands/resolved.py
delete mode 100644 stgit/commands/rm.py
create mode 100644 stgit/lib/__init__.py
create mode 100644 stgit/lib/git.py
create mode 100644 stgit/lib/stack.py
create mode 100644 stgit/lib/stackupgrade.py
create mode 100644 stgit/lib/transaction.py
create mode 100755 t/t1203-push-conflict.sh
create mode 100755 t/t2600-coalesce.sh
create mode 100755 t/t2800-goto-subdir.sh
kha/experimental points to the same commit as kha/safe, for now.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* more than 20 commands in everyday.txt
From: Miklos Vajna @ 2007-12-19 22:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
hi,
this might seem to be a bit bikesheding, but i hope it isn't. today i
teched git to someone who never used any scm so far. i showed him the
"everyday with git" document, as i think it's a great start for newbies.
actually i read it once but it was in the past, now i did it again and i
think there are some commands listed there which is not something we use
"every day". of course it may be only me, that's why i ask. here are the
commands i rarely use and are in everyday.txt:
- git-prune and git-repack: usually i use git-gc only. maybe prune and
repack could be removed from everyday.txt?
- git-show-branch: what about mentioning gitk instead? i think it's much
more used - compared to git-show-branch
what do you think about this? maybe i'm wrong, but if i'm right, then i
would provide a patch to update everyday.txt according to these
suggestions.
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git-to-svn convert
From: Miklos Vajna @ 2007-12-19 23:16 UTC (permalink / raw)
To: Thomas Harning; +Cc: Junio C Hamano, git
In-Reply-To: <476997C1.2080506@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Wed, Dec 19, 2007 at 05:14:25PM -0500, Thomas Harning <harningt@gmail.com> wrote:
> Example of what I mean...:
>
> a - b -
> `c'
>
>
> As to how to pull the repository into subversion.. how would I do that?
> git-svn init ?
i think you have two options:
- use some 3rd-party tool like tailor
- first you should rewrite your history by creating a linear history
then git-svn can dcommit your changes to svn
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: kha/safe updated
From: Catalin Marinas @ 2007-12-19 23:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071219224638.GB15119@diana.vm.bytemark.co.uk>
On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-12-19 23:24:49 +0100, Karl Hasselström wrote:
>
> > And here it is!
>
> And with that, I don't see any reason to not recommend that you pull
> every patch I have. Which is:
Please rebase again when you have time since I already merged most of
this branch and added some patches that might conflict with yours.
--
Catalin
^ 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