* git-svn and migration
From: Nigel Magnay @ 2007-12-19 16:50 UTC (permalink / raw)
To: git
In-Reply-To: <320075ff0712190849u2c40cc46pf01fa2a75f557482@mail.gmail.com>
Hi there!
I've been playing around with git for a while, read the guides to
git-svn and have been successfully using it on my own to track an
upstream svn repository.
Eventually, I'd like us all to switch to git, throw out the svn
server, and replace it with a git repository that can be pushed to,
where commits that pass tests get merged into the master.
But - that's not going to happen overnight. The most likely next steps
are going to be something like migrating a couple of other developers
onto git to test the water, but in the interim most people will still
be on svn.
Has anyone got any tips as I'm sure it's a path trodden before? I've
seen examples of keeping a read-only svn, but that's not really what
I'm after. I'm considering whether to have a central git repo
regularly pull from svn so that it's up to date, and having us
possibly push to svn (or git if it's not merged to trunk) as an
interim step..
Nigel
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 17:02 UTC (permalink / raw)
To: Jakub Narebski
Cc: Karl Hasselström, David Kågedal, git, Theodore Ts'o
In-Reply-To: <200712191723.29591.jnareb@gmail.com>
On 19/12/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> Karl Hasselström wrote:
> > On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:
> >> On Wed, 19 Dec 2007, Karl Hasselström wrote:
> >>> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
> >>>
> >>>> I also would like to have this command kept (and shown in 'stg
> >>>> help'!). Contrary to 'git add' it can check and add to index /
> >>>> update index only for files with conflict; we have -r
> >>>> (ancestor|current|patched) to choose one side, and we could add
> >>>> --check to check if there are no conflict markers with files
> >>>> (useful with -a/--all).
> >>>
> >>> This too sounds like stuff that could profitably be added to "git
> >>> add". Except for the ancestor/current/patched words, it is not
> >>> specific to patch stacks, so the implementation should be in git
> >>> and not in stg.
> >>
> >> No it cannot, at least the '-r (ancestor|current|patched)' part for
> >> resetting file to given version, even if we change the wording to
> >> ancestor, ours and theirs. The git-add command is about adding
> >> contents, which updates index, which almost as a intended
> >> side-effect clears merge state, i.e. stages; and not about resetting
> >> to stage.
> >
> > git checkout-index --stage=1|2|3 <filename>
> >
> > does what you want. But "git cat-file" knows this handy syntax for
> > getting at particular index stages:
> >
> > :stage:<filename>
>
> I always forget which stage is which. It would be nice if
> git-checkout-index implemented human-friendly names, just like
> git-diff-files has --base, --ours, --theirs, i.e. if it would be
> possible to write
>
> git checkout-index --stage=base|ours|theirs <filename>
This gets even more confusing with StGIT. For plain git, after a git
merge or pull conflict, 'theirs' is stage 3. With StGIT, we first
advance the base of the stack and merge the patches onto it, in which
case the 'patched' (which I would normally call 'ours' rather than
'theirs') is 3.
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 17:14 UTC (permalink / raw)
To: Jakub Narebski, Catalin Marinas
Cc: Theodore Ts'o, git, Karl Hasselström
In-Reply-To: <b0943d9e0712190902r2000c1ebob2303b32d1b948b8@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
>> I always forget which stage is which. It would be nice if
>> git-checkout-index implemented human-friendly names, just like
>> git-diff-files has --base, --ours, --theirs, i.e. if it would be
>> possible to write
>>
>> git checkout-index --stage=base|ours|theirs <filename>
>
> This gets even more confusing with StGIT. For plain git, after a git
> merge or pull conflict, 'theirs' is stage 3. With StGIT, we first
> advance the base of the stack and merge the patches onto it, in which
> case the 'patched' (which I would normally call 'ours' rather than
> 'theirs') is 3.
True. And the same problem obviously exists for "git rebase".
--
David Kågedal
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 17:14 UTC (permalink / raw)
To: Jakub Narebski
Cc: Catalin Marinas, David Kågedal, git, Theodore Ts'o
In-Reply-To: <200712191723.29591.jnareb@gmail.com>
On 2007-12-19 17:23:27 +0100, Jakub Narebski wrote:
> Karl Hasselström wrote:
>
> > git checkout-index --stage=1|2|3 <filename>
> >
> > does what you want. But "git cat-file" knows this handy syntax for
> > getting at particular index stages:
> >
> > :stage:<filename>
>
> I always forget which stage is which. It would be nice if
> git-checkout-index implemented human-friendly names, just like
> git-diff-files has --base, --ours, --theirs, i.e. if it would be
> possible to write
>
> git checkout-index --stage=base|ours|theirs <filename>
>
> and perhaps even
>
> :base|ours|theirs:<filename>.
>
> (but there is a problem with files containing ':'...).
<ref>:<path> is already accepted, so I don't think this would be much
worse.
And yes, I agree that the base/ours/theirs aliases are nice, and
should be accepted by at least the porcelain commands.
> > Yes, that's what I want. You and others like what "stg resolved"
> > does, but I don't want it in StGit because it's a generic git
> > enhancement that has nothing to with patch stacks. People who
> > don't use StGit would presumably like it as well.
>
> You mean adding another option to git-add, similar to '-u' option,
> but updating only the files which were (are) in merge conflict;
> '-c'/'-r'/'-s' perhaps?
Yes. That _is_ the operation you want, isn't it?
> This would be replacement for "stg resolved --all", wouldn't it (and
> with filename replacement for "stg resolved <filename>", of course)?
Yes. Though with a filename argument, you wouldn't need the new flag.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: log/show: relative pathnames do not work in rev:path
From: Dana How @ 2007-12-19 17:21 UTC (permalink / raw)
To: Jakub Narebski
Cc: Linus Torvalds, Johannes Schindelin, Alex Riesen, git, danahow
In-Reply-To: <200712191223.42446.jnareb@gmail.com>
On Dec 19, 2007 3:23 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 19 Dec 2007, Dana How wrote:
> > I'd like to move some stuff currently in a p4 repository into git.
> > The directory structure within the repo is 13 levels deep;
> > I didn't design it nor can I change it.
> >
> > ... The
> > basic commit:file syntax doesn't accept relative paths. I am not
> > specifically hung up on the commit:./path syntax; I just want some
> > notation that will get those 13 directories from $cwd instead of
> > making me type them again.
>
> I think new feature like this should be postponed after 1.5.4 is out;
> we are now in feature freeze (only bugfixes are accepted).
OK. This is all the conversation that resulted from Alex's RFC.
> 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
(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.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Dana How @ 2007-12-19 17:40 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Linus Torvalds, Alex Riesen, Jakub Narebski,
git, danahow
In-Reply-To: <20071219150510.GB13942@coredump.intra.peff.net>
On Dec 19, 2007 7:05 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote:
> > When you are in a deeply-nested directory structure, and just want
> > to reference a blob in a past revision, it can be pretty slow to
> > type out "HEAD~29:/bla/blub/.../that-file".
> >
> > This patch makes "HEAD~29:./that-file" substitute the current prefix
> > for "./". If there is not working directory, the prefix is empty.
>
> I think this is definitely the right approach. Here's a (possibly
> insane) alternative. Revert the change in get_sha1_with_mode and detect
> "./" in get_tree_entry:
>
> [..]
>
> This means that the directory '.' becomes a token replacement for "my
> current path" in tree paths. So if you are in "foo/bar", and you are
> looking at a distance commit where the same content was in
> "baz/foo/bar", you can do:
>
> git show distant:baz/./file
>
> This is probably insane because:
> - this is a fairly unlikely use case
> - get_tree_entry gets called in a lot of places, and I have no idea if
> there will be some crazy fallouts.
>
> So it is probably not worth pursuing, but maybe somebody else can think
> of a good use.
For me, I was only interested in the recognition of ./ at the beginning
of a path just after : (causing a cwd suffix to be inserted there).
If there were additional /./ or /../ patterns in the result, I think it
would be more useful (e.g. for script writers who forgot to run
their file arguments thru something like "readlink -f") for them
to be squashed out (e.g. in Perl:
s#/(\./)+#/#g;
s#/([^/]*[^./][^/]*/\.\./)+#/#g;
). But this is something that could be added later if desired to
the interpretation of all paths, and so seems like a different issue.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [PATCH] make 'git describe --all --contains' work
From: Nicolas Pitre @ 2007-12-19 17:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-describe.c b/builtin-describe.c
index 6eeb9b5..7a148a2 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -267,12 +267,14 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
if (contains) {
const char **args = xmalloc((4 + argc) * sizeof(char*));
- args[0] = "name-rev";
- args[1] = "--name-only";
- args[2] = "--tags";
- memcpy(args + 3, argv, argc * sizeof(char*));
- args[3 + argc] = NULL;
- return cmd_name_rev(3 + argc, args, prefix);
+ int i = 0;
+ args[i++] = "name-rev";
+ args[i++] = "--name-only";
+ if (!all)
+ args[i++] = "--tags";
+ memcpy(args + i, argv, argc * sizeof(char*));
+ args[i + argc] = NULL;
+ return cmd_name_rev(i + argc, args, prefix);
}
if (argc == 0) {
^ permalink raw reply related
* Re: git-svn and migration
From: Steven Walter @ 2007-12-19 17:54 UTC (permalink / raw)
To: Nigel Magnay; +Cc: git
In-Reply-To: <320075ff0712190850r35263bcfv1d8f84e699208e15@mail.gmail.com>
On Wed, Dec 19, 2007 at 04:50:30PM +0000, Nigel Magnay wrote:
> Has anyone got any tips as I'm sure it's a path trodden before? I've
> seen examples of keeping a read-only svn, but that's not really what
> I'm after. I'm considering whether to have a central git repo
> regularly pull from svn so that it's up to date, and having us
> possibly push to svn (or git if it's not merged to trunk) as an
> interim step..
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).
I wrote a script that automates most of this stuff (including doing
incremental additions to git-svn's revdb/revmap). If there's interest,
I can see about cleaning it up for general consumption.
--
-Steven Walter <stevenrwalter@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Alex Riesen @ 2007-12-19 18:09 UTC (permalink / raw)
To: Dana How
Cc: Jeff King, Johannes Schindelin, Linus Torvalds, Jakub Narebski,
git
In-Reply-To: <56b7f5510712190940g2a377f4tfe3ca897561ed446@mail.gmail.com>
Dana How, Wed, Dec 19, 2007 18:40:04 +0100:
> If there were additional /./ or /../ patterns in the result, I think it
> would be more useful (e.g. for script writers who forgot to run
> their file arguments thru something like "readlink -f") for them
> to be squashed out (e.g. in Perl:
> s#/(\./)+#/#g;
> s#/([^/]*[^./][^/]*/\.\./)+#/#g;
> ). But this is something that could be added later if desired to
> the interpretation of all paths, and so seems like a different issue.
This is what the pathexpand in pathexpand-patch does.
^ permalink raw reply
* Re: Serious bug with pretty format strings & empty bodies?
From: René Scharfe @ 2007-12-19 18:28 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <57518fd10712190632o490af924n61326fddf1819014@mail.gmail.com>
Jonathan del Strother schrieb:
> 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.
>
> For example, on a private repository, I'm trying to print the subject
> & body of a commit. This particular commit doesn't actually have a
> body, so I'm expecting to see this output :
>
> =================
> commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> Try to flush log files before terminating the app
>
> =================
>
> However, when I actually run the command, I get gibberish in place of %b :
> =================
> $ git rev-list -1- --pretty=format:"%s%n%b"
> 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
> Try to flush log files before terminating the app
> tree 57bc7cf30a10aee96251852125cf30fd2c81d7aa
> parent 04c833865828538315fcdf6e187da077869ce444
> author Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
> committer Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
>
> Check that ThreadWorker's work method actually returns a value with
> method signatures
> =================
>
> So here you can see that the full details of a different commit is
> appearing in place of the requested commit's (empty) body. Rerunning
> the rev-list produces the same output - the same string appears in
> place of %b every time, but it's different for each commit. Often you
> only get a small fragment of another commit's message, rather than the
> full commit as seen above.
>
> When I use --pretty=full, it works fine.
>
> This appears in quite a few places in my repository's history.
> Repacking the repo semi-fixes it - I still get junk bodies, but not
> quite so many.
>
> It doesn't always happen when a commit message body is empty, but I've
> never seen it happen where the message body has something in.
>
> This happens with both git 1.5.3.7 and 1.5.4.rc0.1162.g3bfea, though
> the output is slightly different - the former has a number of
> <unknown> markers in it. This is on OS X 10.5.1
That's strange. Could you check if this happens with e52a5de, too?
That's the commit that introduced --pretty=format. If it doesn't, could
you then please try to bisect the bug?
How many '<unknown>' markers are there in the output of version 1.5.3.7
(and e52a5de)? One per %b? Are they the only output or are they
combined with parts of unrelated commits, too?
Thanks,
René
^ permalink raw reply
* 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
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