* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
From: John Keeping @ 2013-01-23 9:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric S. Raymond, Chris Rorvick
In-Reply-To: <7vobgglpv4.fsf@alter.siamese.dyndns.org>
On Tue, Jan 22, 2013 at 04:11:59PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>> Would you mind holding off on this? As it stands there are a couple of
>> issues with the cvsimport-3 script including: ...
>
> Actually I do. I think this, at least the early part of it, should
> be merged to 'next' as soon as possible, *unless*
>
> (1) The cvsimport-2 & cvsps2 combo this series ships gives worse
> experience than cvsimport we ship in v1.8.1 to end users of the
> current cvsimport with cvsps2; and/or
>
> (2) The cvsimport-3 in this series, which is a copy of an older
> version of what Eric has, is so broken that we are better off
> starting cvsimport-3 by getting a fresh copy from Eric which
> has been rewritten in a major way, than applying huge
> incremental update patches that amounts to a total rewrite.
>
> The point (1) is important from "no regression" point of view, and
> in a sense more important between the two because it is the first
> step in the overall transition plan.
>
> Even though there may be remaining issues in cvsimport-3 and cvsps3
> (what new piece of software don't have issues?), my limited
> observation of the exchanges between you and Eric suggests me that
> the problem is not something that requires a total rewrite of how
> cvsimport-3 works, so I do not expect the point (2) to be true,
> either, but if I am mistaken, please let me know.
ESR's cvsimport.py in the cvsps repository has no fixes over what's
here. I think his comment in [1] indicates that he won't do any more
work on git-cvsimport.
[1] http://article.gmane.org/gmane.comp.version-control.git/214057
In my opinion the incremental import support really is substantially
worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output
of git-for-each-ref to calculate the dates from which to continue each
branch. cvsps cannot be told this information and so the cvsimport-3
script just takes the date of the last commit on the current branch.
On top of that, the incremental switch to cvsps-3 just causes it to
output:
from: refs/heads/branch^0
on the first commit for each branch, which I can't see working if a new
branch is created in CVS.
> By advancing the topic to 'next', we will give people a more solid
> (read: not getting rewound) foundation to work with than "if you are
> really interested, grab the tip of 'pu', replace it with even newer
> copy from Eric's repository and try it out", so that more people can
> help us polish the scaffolding to let us ship two versions and also
> find issues in the new cvsimport-3 and help fixing them. At least,
> that is what I've been hoping.
That's what I've done and it's convinced me that cvsps-3 is not ready
for use with incremental imports as it stands.
> I could stop at the first three patches, that is, introducing the
> version switch wrapper that switches between cvsps2+cvsimport-2
> combo and nothing, and then let you and Eric redo the "start adding
> cvsps 3.x support" and later patches when cvsimport-3 is ready.
> That would give you a larger lattitude to rework cvsimport-3. Is
> that preferrable?
My preference would be for something like this, possibly with an
expanded examples section showing how to pipe the output of cvsps-3 or
cvs2git into git-fast-import:
-- >8 --
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 9d5353e..20b846e 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -18,6 +18,11 @@ SYNOPSIS
DESCRIPTION
-----------
+*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
+deprecated; it does not work with cvsps version 3 and later. If you are
+performing a one-shot import of a CVS repository consider using cvsps-3,
+cvs2git or parsecvs directly.
+
Imports a CVS repository into git. It will either create a new
repository, or incrementally import into an existing one.
-- 8< --
John
^ permalink raw reply related
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: Michael Haggerty @ 2013-01-23 9:54 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Junio C Hamano, John Keeping, git
In-Reply-To: <CAEUsAPaw8EUcZFbODDj9Z-=3Ppd1CC=jvYDvuyntFkX_3V0ynQ@mail.gmail.com>
On 01/20/2013 09:17 PM, Chris Rorvick wrote:
> I probably won't be sending any more patches on this. My hope was to
> get cvsimport-3 (w/ cvsps as the engine) in a state such that one
> could transition from the previous version seamlessly. But the break
> in t9605 has convinced me this is not worth the effort--even in this
> trivial case cvsps is broken. The fuzzing logic aggregates commits
> into patch sets that have timestamps within a specified window and
> otherwise matching attributes. This aggregation causes file-level
> commit timestamps to be lost and we are left with a single timestamp
> for the patch set: the minimum for all contained CVS commits. When
> all commits have been processed, the patch sets are ordered
> chronologically and printed.
>
> The problem is that is that a CVS commit is rolled into a patch set
> regardless of whether the patch set's timestamp falls within the
> adjacent CVS file-level commits. Even worse, since the patch set
> timestamp changes as subsequent commits are added (i.e., it's always
> picking the earliest) it is potentially indeterminate at the time a
> commit is added. The result is that file revisions can be reordered
> in resulting Git import (see t9605.) I spent some time last week
> trying to solve this but I coudln't think of anything that wasn't a
> substantial re-work of the code.
>
> I have never used cvs2git, but I suspect Eric's efforts in making it a
> potential backend for cvsimport are a better use of time.
Thanks for your explanation of how cvsps works.
This is roughly how cvs2svn used to work years ago, prior to release
2.x. In addition it did a number of things to try to tweak the
timestamp ordering to avoid committing file-level commits in the wrong
order. It never worked 100%; each tweak that was made to fix one
problem created another problem in another scenario.
cvs2svn/cvs2git 2.x takes a very different approach. It uses a
timestamp threshold along with author and commit-message matching to
find the biggest set of file-level commits that might constitute a
repository-level commit. But then it checks the proto-commits to see if
they violate the ordering constraints imposed by the individual
file-level commits. For example, if the initial grouping gives the
following proto-commits:
proto-commit 1: a.txt 1.1 b.txt 1.2
proto-commit 2: a.txt 1.2 b.txt 1.1
then it is apparent that something is wrong, because a.txt 1.1
necessarily comes before a.txt 1.2 whereas b.txt 1.1 necessarily comes
before b.txt 1.2 (CVS can at least be relied on to get this right!) and
therefore there is no consistent ordering of the two proto-commits.
More generally, the proto-commits have to form a directed acyclic graph,
whereas this graph has a cycle 1 -> 2 -> 1. When cvs2svn/cvs2git finds
a cycle, it uses heuristics to break up one or more of the proto-commits
to break the cycle. In this case it might break proto-commit 1 into two
commits:
proto-commit 1a: a.txt 1.1
proto-commit 2: a.txt 1.2 b.txt 1.1
proto-commit 1b: b.txt 1.2
Now it is possible to commit them in the order 1a,2,1b. (Exactly this
scenario is tested in t9603.)
Of course a typical proto-commit graph often contains far more
complicated cycles, but the approach remains the same: split
proto-commits up as necessary until the graph is acyclic. One can
quibble about the heuristics that cvs2svn/cvs2git uses to break up
proto-commits. But the final result of the algorithm is *guaranteed* to
be consistent with the file-level CVS history and also self-consistent.
I am skeptical that a simpler approach will ever work 100%.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH v2] all: new command used for multi-repo operations
From: Duy Nguyen @ 2013-01-23 10:15 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <CAFXTnz6mU999DBQG9mPKyjtit4e4WF=bUf_E8XwGR8d5sUPO0w@mail.gmail.com>
On Wed, Jan 23, 2013 at 4:24 PM, Lars Hjemli <hjemli@gmail.com> wrote:
> On Wed, Jan 23, 2013 at 9:55 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> Perhaps we could add the subrepo's object data to the in-memory object
>> database of git-all, then do the diff without launching new commands?
>
> The `git all` command is regularly invoked outside of git repos, so
> I'm not sure if this would work.
We could initialize an empty object database in memory. But my
suggestion is probably off topic. I thought this was about a a git
repository with a collection of submodules. If there are no
connections between repos, perhaps git-all fits better as a subcommand
of git-repo:
http://source.android.com/source/version-control.html
--
Duy
^ permalink raw reply
* git-svn problems with white-space in tag names
From: Hans-Juergen Euler @ 2013-01-23 10:23 UTC (permalink / raw)
To: git
I have discussed already the problem a bit more in this thread
groups.google.com/d/topic/git-users/kfMFZ3uEFsM/discussion
-----Operating system (specifically which version)
windows 7 64 bit
------Git version (git --version)
Git version 1.8.0 for windows obviously.
git bash and git gui installed and using
------Git configuration (system, home, repository)
hmm guess is covered with git bash and git gui. Using the standard config stuff
using subversion
TortoiseSVN 1.7.11
Subversion 1.7.8
Was typically always up-to-date (within 2 months or so) with previous versions
using an external subversion provider for storing the information
externally. guess the version there is older but do not know
I have tried to convert some of my external subversion data bases with
git-svn clone
I have encountered a problem with one of my subversion repos. I have
obviously introduced about 2 years ago a problem with an additional
white space at the end of tag name.
So there is an entry "tags/blabla "
in the subversion repos. The sequential handling of the svn repos with
git-svn gets stuck there. I could not find a way around this. My guess
is that the white-space was introduced by accident on windows by
Tortoise-SVN.
Unfortunately this occurs at revision 90 something and I have almost
1000 revisions stored.
Let me know if you need more details.Thanks.
^ permalink raw reply
* git-svn does not like format=4
From: Hans-Juergen Euler @ 2013-01-23 10:43 UTC (permalink / raw)
To: git
it's part of a sequence of problems you can find on
groups.google.com/d/topic/git-users/kfMFZ3uEFsM/discussion
windows 7 64 bit
Git version 1.8.0
git bash and git gui installed and using
using subversion
TortoiseSVN 1.7.11
Subversion 1.7.8
Was typically always up-to-date (within 2 months or so) with previous versions
using an external subversion provider for storing the information
externally. guess the version there is older but do not know
I have dumped the content of an external subversion repos and created
a local repos with aforementioned version.
when cloning the subversion repos with "git-svn clone" I received this
error message:
Expected FS format '2'; found format '4' at
/usr/lib/perl5/site_perl/Git/SVN.pm line 148
Please let me know if you need more details.Thanks
^ permalink raw reply
* Re: git-svn does not like format=4
From: Erik Faye-Lund @ 2013-01-23 11:00 UTC (permalink / raw)
To: Hans-Juergen Euler; +Cc: GIT Mailing-list, msysGit
In-Reply-To: <CAK3CF+5uD92pdEaoq4e1fwi_YxkM3ddzAUqYKO1rW5BY9rPdCA@mail.gmail.com>
On Wed, Jan 23, 2013 at 11:43 AM, Hans-Juergen Euler
<waas.nett@gmail.com> wrote:
> it's part of a sequence of problems you can find on
> groups.google.com/d/topic/git-users/kfMFZ3uEFsM/discussion
>
> windows 7 64 bit
> Git version 1.8.0
> git bash and git gui installed and using
>
> using subversion
> TortoiseSVN 1.7.11
> Subversion 1.7.8
> Was typically always up-to-date (within 2 months or so) with previous versions
>
> using an external subversion provider for storing the information
> externally. guess the version there is older but do not know
>
> I have dumped the content of an external subversion repos and created
> a local repos with aforementioned version.
> when cloning the subversion repos with "git-svn clone" I received this
> error message:
> Expected FS format '2'; found format '4' at
> /usr/lib/perl5/site_perl/Git/SVN.pm line 148
This isn't a problem with Git itself, but with Git for Windows not
having an up-to-date build of libsvn.
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH 0/3] fixup remaining cvsimport tests
From: John Keeping @ 2013-01-23 11:03 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Chris Rorvick, Junio C Hamano, git
In-Reply-To: <50FFB35C.7070809@alum.mit.edu>
On Wed, Jan 23, 2013 at 10:54:36AM +0100, Michael Haggerty wrote:
> On 01/20/2013 09:17 PM, Chris Rorvick wrote:
>> I have never used cvs2git, but I suspect Eric's efforts in making it a
>> potential backend for cvsimport are a better use of time.
Is it possible to perform an incremental import with cvs2git? This
seems to be the one use case where the old cvsimport script (with cvsps
2.x) still performs the best.
I suppose that just re-running the full import will do the right thing
since the commits in Git should be identical, but would it be possible
to do better given the right information about a previous run?
John
^ permalink raw reply
* Re: Bug in latest gitk - can't click lines connecting commits
From: Paul Mackerras @ 2013-01-23 11:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v622p9lfs.fsf@alter.siamese.dyndns.org>
On Tue, Jan 22, 2013 at 09:28:23AM -0800, Junio C Hamano wrote:
>
> I notice that I have a handful of commits that I haven't pulled from
> your repository, and the last commit on your 'master' is about 20
> days old. Is it safe for me to pull these now?
Yes, please pull them now.
Regards,
Paul.
^ permalink raw reply
* Moving commits from one branch to another
From: Stefan Schulze @ 2013-01-23 12:04 UTC (permalink / raw)
To: git
Hi,
my team uses a central git-repo since >1500 commits and now we have to sync
(only one-way is necessary for now) our repository every three weeks with an
external svn-repo.
I created the new base-directory (incl. trunk/tags/branches) in svn and
added it to my local repo using git svn init && git fetch.
Now I have two branches in my local repository (master and "svnbranch") and
cherry-picked the very first commit from master to svnbranch (it was
probably not necessary), tagged this commit as "publishedToSvn". Now I want
to add all commits publishedToSvn..master onto svnbranch. I didn't managed
to succeed using git-rebase (probably because of the missing common
commits?) and using git grafts / filter-branch modifies my already published
master.
Is there any way to move/copy commits from one branch to another without a
common base-commit and without a forced push of master?
Thanks in advance,
Stefan Schulze
^ permalink raw reply
* Re: [PATCH v3 0/2] Make git-svn work with gitdir links
From: Barry Wardell @ 2013-01-23 12:08 UTC (permalink / raw)
To: git
In-Reply-To: <20130123023235.GA24135@dcvr.yhbt.net>
On Wed, Jan 23, 2013 at 2:32 AM, Eric Wong <normalperson@yhbt.net> wrote:
>
> Barry Wardell <barry.wardell@gmail.com> wrote:
> > These patches fix a bug which prevented git-svn from working with repositories
> > which use gitdir links.
> >
> > Changes since v2:
> > - Rebased onto latest master.
> > - Added test case which verifies that the problem has been fixed.
> > - Fixed problems with git svn (init|clone|multi-init).
> > - All git-svn test cases now pass (except two in t9101 which also failed
> > before these patches).
>
> t9101 did not fail for me before your patches. However I have a
> patch on top of your 2/2 which should fix things.
>
> `git rev-parse --show-cdup` outputs nothing if GIT_DIR is set,
> so I unset GIT_DIR temporarily.
>
> I'm not sure why --show-cdup behaves like this, though..
>
> Does squashing this on top of your changes fix all your failures?
> I plan on squashing both your changes together with the below:
>
> diff --git a/git-svn.perl b/git-svn.perl
> index c232798..e5bd292 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -332,11 +332,13 @@ if ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
> $ENV{GIT_DIR} = command_oneline([qw/rev-parse --git-dir/]);
> } "Unable to find .git directory\n";
> my $cdup = undef;
> + my $git_dir = delete $ENV{GIT_DIR};
> git_cmd_try {
> $cdup = command_oneline(qw/rev-parse --show-cdup/);
> chomp $cdup if ($cdup);
> $cdup = "." unless ($cdup && length $cdup);
> - } "Already at toplevel, but $ENV{GIT_DIR} not found\n";
> + } "Already at toplevel, but $git_dir not found\n";
> + $ENV{GIT_DIR} = $git_dir;
> chdir $cdup or die "Unable to chdir up to '$cdup'\n";
> $_repository = Git->repository(Repository => $ENV{GIT_DIR});
> }
Yes, I can confirm that applying this patch on top of mine makes all
git-svn tests pass again. I have also re-run the tests without my
patch applied and found that they do all indeed pass, so I apologize
for my previous incorrect comment.
^ permalink raw reply
* Re: Moving commits from one branch to another
From: John Keeping @ 2013-01-23 12:12 UTC (permalink / raw)
To: Stefan Schulze; +Cc: git
In-Reply-To: <000a01cdf961$bcf773d0$36e65b70$@de>
On Wed, Jan 23, 2013 at 01:04:03PM +0100, Stefan Schulze wrote:
> my team uses a central git-repo since >1500 commits and now we have to sync
> (only one-way is necessary for now) our repository every three weeks with an
> external svn-repo.
> I created the new base-directory (incl. trunk/tags/branches) in svn and
> added it to my local repo using git svn init && git fetch.
> Now I have two branches in my local repository (master and "svnbranch") and
> cherry-picked the very first commit from master to svnbranch (it was
> probably not necessary), tagged this commit as "publishedToSvn". Now I want
> to add all commits publishedToSvn..master onto svnbranch. I didn't managed
> to succeed using git-rebase (probably because of the missing common
> commits?) and using git grafts / filter-branch modifies my already published
> master.
>
> Is there any way to move/copy commits from one branch to another without a
> common base-commit and without a forced push of master?
Did you try "git rebase" with "--onto"? You probably want something
like this:
git rebase --onto svnbranch publishedToSvn master
John
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
From: Chris Rorvick @ 2013-01-23 13:26 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git, Eric S. Raymond
In-Reply-To: <20130123092858.GJ7498@serenity.lan>
On Wed, Jan 23, 2013 at 3:28 AM, John Keeping <john@keeping.me.uk> wrote:
> In my opinion the incremental import support really is substantially
> worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output
> of git-for-each-ref to calculate the dates from which to continue each
> branch. cvsps cannot be told this information and so the cvsimport-3
> script just takes the date of the last commit on the current branch.
Do you really need a timestamp per branch, though? If you have
branches A and B, and B has a commit timestamp 5 minutes after A, you
can infer that nothing happened on A for those five minutes, right?
So maybe a single timestamp is sufficient, it just may not be picking
the right one. Instead cvsimport-3 should compute the latest
timestamp across all import branches.
Chris
^ permalink raw reply
* [PATCH/RFC] Revoke write access to refs and odb after importing another repo's odb
From: Nguyễn Thái Ngọc Duy @ 2013-01-23 13:34 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann, Nguyễn Thái Ngọc Duy
add_submodule_odb() can be used to import objects from another
repository temporarily. After this point we don't know which objects
are ours, which are external. If we create an object that refers to an
external object, next time git runs, it may find a hole in the object
graph because the external repository may not be imported. The same
goes for pointing a ref to an external SHA-1.
To protect ourselves, once add_submodule_odb() is used:
- trees, tags and commits cannot be created
- refs cannot be updated
In certain cases that submodule code knows that it's safe to write, it
can turn the readonly flag off.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I think this is a good safety check. It catches at least a case in
t7405.3. I did not investigate further though.
cache.h | 1 +
refs.c | 2 ++
sha1_file.c | 2 ++
submodule.c | 7 +++++++
5 files changed, 16 insertions(+)
diff --git a/cache.h b/cache.h
index c257953..772d229 100644
--- a/cache.h
+++ b/cache.h
@@ -753,6 +753,7 @@ extern int force_object_loose(const unsigned char *sha1, time_t mtime);
extern void *map_sha1_file(const unsigned char *sha1, unsigned long *size);
extern int unpack_sha1_header(git_zstream *stream, unsigned char *map, unsigned long mapsize, void *buffer, unsigned long bufsiz);
extern int parse_sha1_header(const char *hdr, unsigned long *sizep);
+extern int git_repo_readonly();
/* global flag to enable extra checks when accessing packed objects */
extern int do_check_packed_object_crc;
diff --git a/refs.c b/refs.c
index 541fec2..22b13f4 100644
--- a/refs.c
+++ b/refs.c
@@ -1711,6 +1711,8 @@ struct ref_lock *lock_ref_sha1(const char *refname, const unsigned char *old_sha
struct ref_lock *lock_any_ref_for_update(const char *refname,
const unsigned char *old_sha1, int flags)
{
+ if (git_repo_readonly())
+ die("repository in read-only mode, cannot update refs");
if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL))
return NULL;
return lock_ref_sha1_basic(refname, old_sha1, flags, NULL);
diff --git a/sha1_file.c b/sha1_file.c
index 40b2329..b9e8b59 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2575,6 +2575,8 @@ int write_sha1_file(const void *buf, unsigned long len, const char *type, unsign
char hdr[32];
int hdrlen;
+ if (git_repo_readonly() && strcmp(type, "blob"))
+ die("repository in read-only mode, cannot update object database");
/* Normally if we have it in the pack then we do not bother writing
* it out into .git/objects/??/?{38} file.
*/
diff --git a/submodule.c b/submodule.c
index 2f55436..5eba597 100644
--- a/submodule.c
+++ b/submodule.c
@@ -19,6 +19,7 @@ static struct string_list changed_submodule_paths;
static int initialized_fetch_ref_tips;
static struct sha1_array ref_tips_before_fetch;
static struct sha1_array ref_tips_after_fetch;
+static int readonly;
/*
* The following flag is set if the .gitmodules file is unmerged. We then
@@ -30,6 +31,11 @@ static struct sha1_array ref_tips_after_fetch;
*/
static int gitmodules_is_unmerged;
+int git_repo_readonly()
+{
+ return readonly;
+}
+
static int add_submodule_odb(const char *path)
{
struct strbuf objects_directory = STRBUF_INIT;
@@ -67,6 +73,7 @@ static int add_submodule_odb(const char *path)
/* add possible alternates from the submodule */
read_info_alternates(objects_directory.buf, 0);
prepare_alt_odb();
+ readonly = 1;
done:
strbuf_release(&objects_directory);
return ret;
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [PATCH/RFC] Revoke write access to refs and odb after importing another repo's odb
From: Duy Nguyen @ 2013-01-23 13:38 UTC (permalink / raw)
To: git; +Cc: Jens Lehmann
In-Reply-To: <1358948067-2792-1-git-send-email-pclouds@gmail.com>
On Wed, Jan 23, 2013 at 8:34 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> add_submodule_odb() can be used to import objects from another
> repository temporarily. After this point we don't know which objects
> are ours, which are external. If we create an object that refers to an
> external object, next time git runs, it may find a hole in the object
> graph because the external repository may not be imported. The same
> goes for pointing a ref to an external SHA-1.
>
> To protect ourselves, once add_submodule_odb() is used:
>
> - trees, tags and commits cannot be created
> - refs cannot be updated
.. and soon after I pressed send, I realized I missed at least two
other places write should not be allowed:
- index
- reflog
But the general idea is probably more important than implementation
details at this stage.
--
Duy
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #08; Tue, 22)
From: John Keeping @ 2013-01-23 13:55 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Junio C Hamano, git, Eric S. Raymond
In-Reply-To: <CAEUsAPaUy5ug0_HPjWDTSnAG0kURhP-1-9nOu9_Tpn5nEv6N_Q@mail.gmail.com>
On Wed, Jan 23, 2013 at 07:26:24AM -0600, Chris Rorvick wrote:
> On Wed, Jan 23, 2013 at 3:28 AM, John Keeping <john@keeping.me.uk> wrote:
> > In my opinion the incremental import support really is substantially
> > worse in cvsimport-3 than cvsimport-2. cvsimport-2 looks at the output
> > of git-for-each-ref to calculate the dates from which to continue each
> > branch. cvsps cannot be told this information and so the cvsimport-3
> > script just takes the date of the last commit on the current branch.
>
> Do you really need a timestamp per branch, though? If you have
> branches A and B, and B has a commit timestamp 5 minutes after A, you
> can infer that nothing happened on A for those five minutes, right?
> So maybe a single timestamp is sufficient, it just may not be picking
> the right one. Instead cvsimport-3 should compute the latest
> timestamp across all import branches.
The problem is telling which is an import branch, since it currently
just used "refs/heads/<branch>".
I do have a change to write the timestamp to a file, which takes the
newest commit across all of the branches that have changed during an
import. That may well be good enough but doesn't let you incrementally
update a repository that has been cloned from elsewhere.
John
^ permalink raw reply
* Minor gitk bug - update on empty project : can't read "viewmainheadid_orig(1)": no such variable
From: Indigo Frankencastle @ 2013-01-23 14:00 UTC (permalink / raw)
To: git
One of these "weird usage causes weird bugs".
One way to reproduce:
mkdir foo
cd foo
git init
git commit -am "Initial"
gitk &
# or
gitk --all &
<F5>
Resulting in (gitk-git/gitk line 503 - 512):
can't read "viewmainheadid_orig(1)": no such variable
can't read "viewmainheadid_orig(1)": no such variable
while executing
"if {$mainheadid ne $viewmainheadid_orig($view)} {
if {$showlocalchanges} {
dohidelocalchanges
}
set viewmainheadid($view) $mainheadid
set vie..."
(procedure "updatecommits" line 13)
invoked from within
"updatecommits"
(command bound to event)
As "$mainheadid" is not set, should there be something in the
direction of this perhaps?
...
Subject: [PATCH] gitk catch missing head id on update
---
gitk-git/gitk | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..fa869d7 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -499,6 +499,11 @@ proc updatecommits {} {
set hasworktree [hasworktree]
rereadrefs
+ if {$mainheadid eq ""} {
+ # error_popup "[mc "Error updating commits:"] No main HEAD id"
+ show_status [mc "No main HEAD id"]
+ return {}
+ }
set view $curview
if {$mainheadid ne $viewmainheadid_orig($view)} {
if {$showlocalchanges} {
--
1.7.10.4
...
Or perhaps some logic in:
proc rereadrefs {}
----
Best regards,
IF
^ permalink raw reply related
* AW: Moving commits from one branch to another
From: Stefan Schulze @ 2013-01-23 14:13 UTC (permalink / raw)
To: git
In-Reply-To: <20130123121203.GM7498@serenity.lan>
> > Is there any way to move/copy commits from one branch to another
> > without a common base-commit and without a forced push of master?
>
> Did you try "git rebase" with "--onto"? You probably want something
> like this:
>
> git rebase --onto svnbranch publishedToSvn master
I already tried this some days ago, but wasn't sure about the result. The
resulting history looks exactly what I expected, but all the commits are on
master after executing this commands and svnbranch only contains the
original two commits (svn-commit creating the root directory and the
cherry-picked commit from master)
Does the current branch matter if I call git-rebase with the
<branch>-argument?
^ permalink raw reply
* segmentation fault (nullpointer) with git log --submodule -p
From: Armin @ 2013-01-23 14:38 UTC (permalink / raw)
To: git; +Cc: netzverweigerer
Hello dear git people.
I experience a reproducible segmentation fault on one of my repositories when doing a "git log --submodule -p", tested with newest version on Arch Linux (git version 1.8.1.1) and built fresh (git version 1.8.1.1.347.g9591fcc), tried on 2 seperate systems:
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004b51e5 in parse_commit_header (context=0x7ffff69b6980) at pretty.c:752
752 for (i = 0; msg[i]; i++) {
(gdb) bt
#0 0x00000000004b51e5 in parse_commit_header (context=0x7ffff69b6980) at pretty.c:752
#1 format_commit_one (context=<optimized out>, placeholder=0x526b1e "s", sb=0x7ffff69b6ad0) at pretty.c:1157
#2 format_commit_item (sb=0x7ffff69b6ad0, placeholder=0x526b1e "s", context=<optimized out>) at pretty.c:1224
#3 0x00000000004dacd9 in strbuf_expand (sb=sb@entry=0x7ffff69b6ad0, format=0x526b1e "s", format@entry=0x526b18 " %m %s", fn=fn@entry=0x4b4730 <format_commit_item>, context=context@entry=0x7ffff69b6980)
at strbuf.c:247
#4 0x00000000004b5816 in format_commit_message (commit=commit@entry=0x1ffafd8, format=format@entry=0x526b18 " %m %s", sb=sb@entry=0x7ffff69b6ad0, pretty_ctx=pretty_ctx@entry=0x7ffff69b6af0) at pretty.c:1284
#5 0x00000000004dde52 in print_submodule_summary (reset=0x754640 "\033[m", add=0x754708 "\033[32m", del=0x7546e0 "\033[31m", f=0x7f0685bac7a0, rev=0x7ffff69b6b40) at submodule.c:236
#6 show_submodule_summary (f=0x7f0685bac7a0, path=<optimized out>, one=one@entry=0x1ff2af0 "\020\\vC\371\070\vJ\352\344\205\340\226u\273\021\372\330\234\004",
two=two@entry=0x2030a60 "\301a(\350\371\372\340mb[խo_\272\301\223V˙", dirty_submodule=<optimized out>, meta=meta@entry=0x754690 "\033[1m", del=del@entry=0x7546e0 "\033[31m", add=0x754708 "\033[32m",
reset=reset@entry=0x754640 "\033[m") at submodule.c:307
#7 0x000000000048dd1d in builtin_diff (name_a=name_a@entry=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog", name_b=name_b@entry=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog",
one=one@entry=0x1ff2af0, two=two@entry=0x2030a60, xfrm_msg=0x2039a20 "\033[1mindex 105c764..c16128e 160000\033[m\n", must_show_header=must_show_header@entry=0, o=o@entry=0x7ffff69b7b88,
complete_rewrite=complete_rewrite@entry=0) at diff.c:2267
#8 0x000000000048e60e in run_diff_cmd (pgm=pgm@entry=0x0, name=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog", other=<optimized out>,
attr_path=attr_path@entry=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog", one=one@entry=0x1ff2af0, two=two@entry=0x2030a60, msg=msg@entry=0x7ffff69b74b0, o=o@entry=0x7ffff69b7b88, p=p@entry=0x20371b0)
at diff.c:3057
(gdb) bt
#0 0x00000000004b51e5 in parse_commit_header (context=0x7ffff69b6980) at pretty.c:752
#1 format_commit_one (context=<optimized out>, placeholder=0x526b1e "s", sb=0x7ffff69b6ad0) at pretty.c:1157
#2 format_commit_item (sb=0x7ffff69b6ad0, placeholder=0x526b1e "s", context=<optimized out>) at pretty.c:1224
#3 0x00000000004dacd9 in strbuf_expand (sb=sb@entry=0x7ffff69b6ad0, format=0x526b1e "s", format@entry=0x526b18 " %m %s", fn=fn@entry=0x4b4730 <format_commit_item>, context=context@entry=0x7ffff69b6980)
at strbuf.c:247
#4 0x00000000004b5816 in format_commit_message (commit=commit@entry=0x1ffafd8, format=format@entry=0x526b18 " %m %s", sb=sb@entry=0x7ffff69b6ad0, pretty_ctx=pretty_ctx@entry=0x7ffff69b6af0) at pretty.c:1284
#5 0x00000000004dde52 in print_submodule_summary (reset=0x754640 "\033[m", add=0x754708 "\033[32m", del=0x7546e0 "\033[31m", f=0x7f0685bac7a0, rev=0x7ffff69b6b40) at submodule.c:236
#6 show_submodule_summary (f=0x7f0685bac7a0, path=<optimized out>, one=one@entry=0x1ff2af0 "\020\\vC\371\070\vJ\352\344\205\340\226u\273\021\372\330\234\004",
two=two@entry=0x2030a60 "\301a(\350\371\372\340mb[խo_\272\301\223V˙", dirty_submodule=<optimized out>, meta=meta@entry=0x754690 "\033[1m", del=del@entry=0x7546e0 "\033[31m", add=0x754708 "\033[32m",
reset=reset@entry=0x754640 "\033[m") at submodule.c:307
#7 0x000000000048dd1d in builtin_diff (name_a=name_a@entry=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog", name_b=name_b@entry=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog",
one=one@entry=0x1ff2af0, two=two@entry=0x2030a60, xfrm_msg=0x2039a20 "\033[1mindex 105c764..c16128e 160000\033[m\n", must_show_header=must_show_header@entry=0, o=o@entry=0x7ffff69b7b88,
complete_rewrite=complete_rewrite@entry=0) at diff.c:2267
#8 0x000000000048e60e in run_diff_cmd (pgm=pgm@entry=0x0, name=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog", other=<optimized out>,
attr_path=attr_path@entry=0x1ff2b50 "Packages/Application/Amadeus.Somea.Dialog", one=one@entry=0x1ff2af0, two=two@entry=0x2030a60, msg=msg@entry=0x7ffff69b74b0, o=o@entry=0x7ffff69b7b88, p=p@entry=0x20371b0)
at diff.c:3057
#9 0x000000000048eb3d in run_diff (o=0x7ffff69b7b88, p=0x20371b0) at diff.c:3145
#10 diff_flush_patch (o=0x7ffff69b7b88, p=0x20371b0) at diff.c:3979
#11 diff_flush_patch (p=0x20371b0, o=0x7ffff69b7b88) at diff.c:3970
#12 0x000000000048f15f in diff_flush (options=options@entry=0x7ffff69b7b88) at diff.c:4500
#13 0x00000000004a211a in log_tree_diff_flush (opt=opt@entry=0x7ffff69b7850) at log-tree.c:776
#14 0x00000000004a22b2 in log_tree_diff (log=0x7ffff69b7720, commit=0x1ffdf60, opt=0x7ffff69b7850) at log-tree.c:836
#15 log_tree_commit (opt=opt@entry=0x7ffff69b7850, commit=commit@entry=0x1ffdf60) at log-tree.c:859
#16 0x00000000004393d3 in cmd_log_walk (rev=rev@entry=0x7ffff69b7850) at builtin/log.c:310
#17 0x0000000000439f38 in cmd_log (argc=3, argv=0x7ffff69b80c0, prefix=0x0) at builtin/log.c:582
#18 0x0000000000405978 in run_builtin (argv=0x7ffff69b80c0, argc=3, p=0x74fd20) at git.c:281
#19 handle_internal_command (argc=3, argv=0x7ffff69b80c0) at git.c:442
#20 0x0000000000404de2 in run_argv (argv=0x7ffff69b7f50, argcp=0x7ffff69b7f5c) at git.c:488
#21 main (argc=3, argv=0x7ffff69b80c0) at git.c:563
(gdb) f 0
#0 0x00000000004b51e5 in parse_commit_header (context=0x7ffff69b6980) at pretty.c:752
752 for (i = 0; msg[i]; i++) {
(gdb) l
747 static void parse_commit_header(struct format_commit_context *context)
748 {
749 const char *msg = context->message;
750 int i;
751
752 for (i = 0; msg[i]; i++) {
753 int eol;
754 for (eol = i; msg[eol] && msg[eol] != '\n'; eol++)
755 ; /* do nothing */
756
(gdb) p msg
$7 = <optimized out>
(gdb) p context->message
$8 = 0x0
(gdb) x/8i $pc
=> 0x4b51e5 <format_commit_item+2741>: movzbl (%rcx),%eax
0x4b51e8 <format_commit_item+2744>: mov %rcx,0x18(%rsp)
0x4b51ed <format_commit_item+2749>: mov %rcx,%r10
0x4b51f0 <format_commit_item+2752>: test %al,%al
0x4b51f2 <format_commit_item+2754>: je 0x4b52a3 <format_commit_item+2931>
0x4b51f8 <format_commit_item+2760>: nopl 0x0(%rax,%rax,1)
0x4b5200 <format_commit_item+2768>: test %al,%al
0x4b5202 <format_commit_item+2770>: je 0x4b529e <format_commit_item+2926>
(gdb) i r rcx
rcx 0x0 0
Does this help in any way? Can i provide any further information that helps?
Many thanks for reading this and all the best,
Armin
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Sébastien Boisvert @ 2013-01-23 14:45 UTC (permalink / raw)
To: Thomas Rast
Cc: Eric Chamberland, Brian J. Murrell, git, kusmabite,
Pyeron, Jason J CTR (US), Maxime Boissonneault, Philippe Vaucher
In-Reply-To: <878v7keuh3.fsf@pctrast.inf.ethz.ch>
On 01/22/2013 05:14 PM, Thomas Rast wrote:
> Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
>
>> So, hum, do we have some sort of conclusion?
>>
>> Shall it be a fix for git to get around that lustre "behavior"?
>>
>> If something can be done in git it would be great: it is a *lot*
>> easier to change git than the lustre filesystem software for a cluster
>> in running in production mode... (words from cluster team) :-/
>
> I thought you already established that simply disabling the progress
> display is a sufficient workaround? If that doesn't help, you can try
> patching out all use of SIGALRM within git.
>
In git (9591fcc6d66), I have found these SIGALRM signal handling:
builtin/log.c:268: sigaction(SIGALRM, &sa, NULL);
builtin/log.c:285: signal(SIGALRM, SIG_IGN);
compat/mingw.c:1590: mingw_raise(SIGALRM);
compat/mingw.c:1666: if (sig != SIGALRM)
compat/mingw.c:1668: error("sigaction only implemented for SIGALRM");
compat/mingw.c:1683: case SIGALRM:
compat/mingw.c:1702: case SIGALRM:
compat/mingw.c:1706: exit(128 + SIGALRM);
compat/mingw.c:1708: timer_fn(SIGALRM);
compat/mingw.h:42:#define SIGALRM 14
perl/Git/SVN.pm:2121: SIGALRM, SIGUSR1, SIGUSR2);
progress.c:56: sigaction(SIGALRM, &sa, NULL);
progress.c:68: signal(SIGALRM, SIG_IGN);
I suppose that compat/mingw.{h,c} and SVN.pm can be ignored as our patch to work
around this problem won't be pushed upstream because the real problem is not in git, right ?
If I understand correctly, some VFS system calls get interrupted by SIGALRM, but when
they resume (via SA_RESTART) they return EINTR. Thomas said that these failed calls may need to be retried,
but that open(O_CREAT|O_EXCL) is still tricky around this case.
progress.c SIGALRM code paths are for progress and therefore are required, right ?
builtin/log.c SIGALRM code paths are for early output, and the comments in the code say that
"If we can get the whole output in less than a tenth of a second, don't even bother doing the
early-output thing."
So where do I start for the patch ?
> Other than that I agree with Junio, from what we've seen so far, Lustre
> returns EINTR on all sorts of calls that simply aren't allowed to do so.
>
--
---
Spécialiste en granularité (1 journée / semaine)
Calcul Québec / Calcul Canada
Pavillon Adrien-Pouliot, Université Laval, Québec (Québec), Canada
^ permalink raw reply
* Re: Moving commits from one branch to another
From: John Keeping @ 2013-01-23 14:49 UTC (permalink / raw)
To: Stefan Schulze; +Cc: git
In-Reply-To: <000b01cdf973$cc685fc0$65391f40$@de>
On Wed, Jan 23, 2013 at 03:13:19PM +0100, Stefan Schulze wrote:
> > > Is there any way to move/copy commits from one branch to another
> > > without a common base-commit and without a forced push of master?
> >
> > Did you try "git rebase" with "--onto"? You probably want something
> > like this:
> >
> > git rebase --onto svnbranch publishedToSvn master
>
> I already tried this some days ago, but wasn't sure about the result. The
> resulting history looks exactly what I expected, but all the commits are on
> master after executing this commands and svnbranch only contains the
> original two commits (svn-commit creating the root directory and the
> cherry-picked commit from master)
Ah, I missed that you wanted to update svnbranch. I don't think there's
a single command that will do that, but this should work:
git rebase --onto svnbranch publishedToSvn master^0
git checkout -B svnbranch HEAD
This uses a detached head to avoid modifying the wrong branch and then
updates "svnbranch" to point at that after the rebase.
> Does the current branch matter if I call git-rebase with the
> <branch>-argument?
No it will checkout that branch first.
John
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Sébastien Boisvert @ 2013-01-23 14:50 UTC (permalink / raw)
To: Thomas Rast
Cc: Eric Chamberland, Brian J. Murrell, git, kusmabite,
Pyeron, Jason J CTR (US), Maxime Boissonneault, Philippe Vaucher
In-Reply-To: <878v7keuh3.fsf@pctrast.inf.ethz.ch>
[I forgot to subscribe to the git mailing list, sorry for that]
On 01/22/2013 05:14 PM, Thomas Rast wrote:
> Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
>
>> So, hum, do we have some sort of conclusion?
>>
>> Shall it be a fix for git to get around that lustre "behavior"?
>>
>> If something can be done in git it would be great: it is a *lot*
>> easier to change git than the lustre filesystem software for a cluster
>> in running in production mode... (words from cluster team) :-/
>
> I thought you already established that simply disabling the progress
> display is a sufficient workaround? If that doesn't help, you can try
> patching out all use of SIGALRM within git.
>
In git (9591fcc6d66), I have found these SIGALRM signal handling:
builtin/log.c:268: sigaction(SIGALRM, &sa, NULL);
builtin/log.c:285: signal(SIGALRM, SIG_IGN);
compat/mingw.c:1590: mingw_raise(SIGALRM);
compat/mingw.c:1666: if (sig != SIGALRM)
compat/mingw.c:1668: error("sigaction only implemented for SIGALRM");
compat/mingw.c:1683: case SIGALRM:
compat/mingw.c:1702: case SIGALRM:
compat/mingw.c:1706: exit(128 + SIGALRM);
compat/mingw.c:1708: timer_fn(SIGALRM);
compat/mingw.h:42:#define SIGALRM 14
perl/Git/SVN.pm:2121: SIGALRM, SIGUSR1, SIGUSR2);
progress.c:56: sigaction(SIGALRM, &sa, NULL);
progress.c:68: signal(SIGALRM, SIG_IGN);
I suppose that compat/mingw.{h,c} and SVN.pm can be ignored as our patch to work
around this problem won't be pushed upstream because the real problem is not in git, right ?
If I understand correctly, some VFS system calls get interrupted by SIGALRM, but when
they resume (via SA_RESTART) they return EINTR. Thomas said that these failed calls may need to be retried,
but that open(O_CREAT|O_EXCL) is still tricky around this case.
progress.c SIGALRM code paths are for progress and therefore are required, right ?
builtin/log.c SIGALRM code paths are for early output, and the comments in the code say that
"If we can get the whole output in less than a tenth of a second, don't even bother doing the
early-output thing."
So where do I start for the patch ?
> Other than that I agree with Junio, from what we've seen so far, Lustre
> returns EINTR on all sorts of calls that simply aren't allowed to do so.
>
--
---
Spécialiste en granularité (1 journée / semaine)
Calcul Québec / Calcul Canada
Pavillon Adrien-Pouliot, Université Laval, Québec (Québec), Canada
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Erik Faye-Lund @ 2013-01-23 15:23 UTC (permalink / raw)
To: Thomas Rast
Cc: Eric Chamberland, Brian J. Murrell, git, Pyeron, Jason J CTR (US),
Maxime Boissonneault, Philippe Vaucher, Sébastien Boisvert
In-Reply-To: <878v7keuh3.fsf@pctrast.inf.ethz.ch>
On Tue, Jan 22, 2013 at 11:14 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
>
> Other than that I agree with Junio, from what we've seen so far, Lustre
> returns EINTR on all sorts of calls that simply aren't allowed to do so.
I don't think this analysis is 100% accurate, POSIX allows error codes
to be generated other than those defined. From
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html:
"Implementations may support additional errors not included in this
list, *may generate errors included in this list under circumstances
other than those described here*, or may contain extensions or
limitations that prevent some errors from occurring."
So I don't think Lustre violates POSIX by erroring with errno=EINTR,
but I also think guarding every single function call for EINTR just to
be safe to be insane :)
However, looking at Eric's log, I can't see that being what has
happened here - grepping it for EINTR does not produce a single match.
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Thomas Rast @ 2013-01-23 15:32 UTC (permalink / raw)
To: kusmabite
Cc: Thomas Rast, Eric Chamberland, Brian J. Murrell, git,
Pyeron, Jason J CTR (US), Maxime Boissonneault, Philippe Vaucher,
Sébastien Boisvert
In-Reply-To: <CABPQNSad1EKbmt3Gjs+uB9fud4YBqmk++5GMqF2s047Lcc8GwQ@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> On Tue, Jan 22, 2013 at 11:14 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
>>
>> Other than that I agree with Junio, from what we've seen so far, Lustre
>> returns EINTR on all sorts of calls that simply aren't allowed to do so.
>
> I don't think this analysis is 100% accurate, POSIX allows error codes
> to be generated other than those defined. From
> http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html:
>
> "Implementations may support additional errors not included in this
> list, *may generate errors included in this list under circumstances
> other than those described here*, or may contain extensions or
> limitations that prevent some errors from occurring."
That same page says, however:
For functions under the Threads option for which [EINTR] is not listed
as a possible error condition in this volume of IEEE Std 1003.1-2001,
an implementation shall not return an error code of [EINTR].
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Erik Faye-Lund @ 2013-01-23 15:32 UTC (permalink / raw)
To: Thomas Rast
Cc: Eric Chamberland, Brian J. Murrell, git, Pyeron, Jason J CTR (US),
Maxime Boissonneault, Philippe Vaucher, Sébastien Boisvert
In-Reply-To: <87d2wvc3v0.fsf@pctrast.inf.ethz.ch>
On Wed, Jan 23, 2013 at 4:32 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> On Tue, Jan 22, 2013 at 11:14 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>>> Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
>>>
>>> Other than that I agree with Junio, from what we've seen so far, Lustre
>>> returns EINTR on all sorts of calls that simply aren't allowed to do so.
>>
>> I don't think this analysis is 100% accurate, POSIX allows error codes
>> to be generated other than those defined. From
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html:
>>
>> "Implementations may support additional errors not included in this
>> list, *may generate errors included in this list under circumstances
>> other than those described here*, or may contain extensions or
>> limitations that prevent some errors from occurring."
>
> That same page says, however:
>
> For functions under the Threads option for which [EINTR] is not listed
> as a possible error condition in this volume of IEEE Std 1003.1-2001,
> an implementation shall not return an error code of [EINTR].
Yes, but surely that's for pthreads functions, no? utime is not one of
those functions...
^ permalink raw reply
* AW: Moving commits from one branch to another
From: Schulze, Stefan @ 2013-01-23 15:44 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <20130123144941.GO7498@serenity.lan>
> git rebase --onto svnbranch publishedToSvn master^0
> git checkout -B svnbranch HEAD
Great! This does exactly what I want!
Thanks for your support,
Stefan Schulze
--------------------------
ckc ag
Sitz:
Am Alten Bahnhof 13
38122 Braunschweig
Telefon +49 (0)531 / 80 110 0
Telefax +49 (0)531 / 80 110 18444
http://www.ckc-group.de
Amtsgericht Braunschweig
HRB 5405
Vorstand:
H.-G. Christian Krentel
(Vorsitzender)
Karsten Kisser
Aufsichtsrat:
Dr. Heinz-Werner Weinrich
(Vorsitzender)
Jens Fokuhl
(stellv. Vorsitzender)
Prof. Dr. Reinhold Haux
Cäsar Jaworski
Dr. Rita Schulz
Thorsten Sponholz
--------------------------
^ 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