* Re: Bug: "git-svn fetch" segfaults on unknown user
From: Jens Seidel @ 2008-11-06 23:08 UTC (permalink / raw)
To: git
In-Reply-To: <20081106154808.GA27102@merkur.sol.de>
On Thu, Nov 06, 2008 at 04:48:09PM +0100, Jens Seidel wrote:
> On Thu, Nov 06, 2008 at 03:43:18PM +0100, Mikael Magnusson wrote:
> > 2008/11/6 Jens Seidel <jensseidel@users.sf.net>:
> > > I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):
> > >
> > > "git-svn fetch" segfaults
>
> "gdb -c core" is useless, it just mentions the error occured in
> "perl git-svn fetch" and there is no stacktrace (don't know how to
> debug perl).
>
> I removed now both [svn] options and it failed again. So it seems a problem
> with file:// access while svn+ssh:// works well.
Could this be possible?
I tried now also to svnsync the same repository on the server which I access with
svn+ssh://. "svn-git fetch" fails on this as well, strange ... The hook scripts
or the property added by "svnsync init" are not responsible, right?
> > Are you sure this isn't the regular svn 1.5.x crash? Ie, does
> > compiling subversion with --disable-runtime-module-search fix it?
No, it did not help.
I tried to reproduce it with a simple svn repository instead of my larger (not
public) one but failed.
What further information do you need? Is there any way to obtain more debug info?
Jens
^ permalink raw reply
* Understanding rebase
From: Yang Zhang @ 2008-11-06 22:23 UTC (permalink / raw)
To: git
What properties must commits have for them to be rebase-able?
One example arrangement that would cause a rebase to fail is:
- change lines 10, 12, 14 in branch A
- change lines 11, 13, 15 in branch B
These changes are commutative (I believe), but that is insufficient for
avoiding conflicts on a rebaes. For a concrete example of this, see:
http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1065&view=markup
Another question that probably gets at the same thing: I understand what
rebasing gives me from a high level (rearranging a branch of commits to
be in a series with another branch), but is there a simple explanation
of how, precisely, this is accomplished?
Thanks in advance!
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-06 21:37 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buoiqr18tdk.fsf@dhapc248.dev.necel.com>
Miles Bader, Thu, Nov 06, 2008 03:45:27 +0100:
> Is there any easy way to cherry pick a _range_ of commits from some other
> branch to the current branch, instead of just one?
>
> I thought maybe git-rebase could be coerced to do this somehow, but I
> couldn't figure a way. [Using git-rebase would be nice because of all the
> useful tools it provides, e.g., the --abort, --continue, and -i options.]
>
git format-patch --full-index --binary --stdout <range...> | git am -3
This will not work if you want to pick a list, not a range, of
commits.
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Robin Rosenberg @ 2008-11-06 21:18 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Shawn O. Pearce, git
In-Reply-To: <200811060228.21124.fg@one2team.net>
torsdag 06 november 2008 02:28:20 skrev Francis Galiegue:
> [...]
>
> > > > > * "git stash": is it supported?
> > > >
> > > > Not in Eclipse, no.
> > >
> > > What do you mean by this?
> >
> > I mean there's no implementation of git stash. Eclipse doesn't
> > support git stash, the notion of the stash, the branch the stash
> > is on. Its not in the Eclipse plugin.
> >
>
> While I'm a total newbie to Eclipse, and not that fluent with Java, this looks
> surprising. Is it really Eclipse that is at fault here? Eclipse saves its
> workspace (whatever it means to "save a workspace") when it exits, isn't
> there an interface that you can implement that does "partial" saves, hence
> git stashes?
The fault is that it has not been implemented yet, It's not Eclipse's fault. The
plugin simply lacks support for it. You can do that with Git though. I use both
tools side by side.
> > > > > * can you "copy" a commit, or even a set of commits, and
> > > > > "cherry-pick" them into another branch? Or even rebase a branch onto
> > > > > antoher?
> > > >
> > > > Not in Eclipse, no.
> > >
> > > Same question... What exactly is the problem with Eclipse wrt this kind
> > > of operation?
> >
> > Its also not implemented in the eclipse UI.
>
> Eclipse has the ability to apply patches AFAIK... Even though this may not be
> equivalent to a git cherry-pick, wouldn't there be a way to extract at least
> the diffs and commit messages and apply?
Sure. Solving everything that is missing is a matter of actually coding the feature.
Unfortunately we have very little time at our disposal, which is why we welcome
contributions.
-- robin
-- robin
^ permalink raw reply
* Re: [PATCH 0/4] replace unsinged long with time_t
From: Daniel Stenberg @ 2008-11-06 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0811061000430.3419@nehalem.linux-foundation.org>
On Thu, 6 Nov 2008, Linus Torvalds wrote:
> In theory, some platform might have a 64-but "unsigned long long" time_t
> even if the architecture is 32-bit (apparently windows used to do that if
> you included <time64.h>, for example), but since we wouldn't take advantage
> of that anyway, even then there is no real advantage.
It could also be worth to notice that there are even 64-bit architectures that
feature 32-bit 'time_t'...
--
/ daniel.haxx.se
^ permalink raw reply
* Re: Git SVN Rebranching Issue
From: Avery Pennarun @ 2008-11-06 20:48 UTC (permalink / raw)
To: Eric Wong; +Cc: Dmitry Potapov, Matt Kern, git
In-Reply-To: <20081106093917.GA15686@untitled>
On Thu, Nov 6, 2008 at 4:39 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Avery Pennarun <apenwarr@gmail.com> wrote:
>> Well, you wouldn't have to rename the existing branch. You would
>> simply create the new @SVN-NUMBER branch when it became clear that
>> that commit is no longer reachable from the undecorated branch ref.
>> Isn't that why the @SVN-NUMBER branches are needed in the first place?
>
> Making @SVN-NUMBER branches for new/latest branches is even more
> confusing. That would mean the user would have to remember the
> @SVN-NUMBER every time they wanted to do operations with the
> recycled branch.
Hmm, I wasn't suggesting using @SVN-NUMBER for the *latest* branches;
you create one for the older branches at the time the old one is
replaced by the new one.
Note that this is exactly how it works in svn, so in fact it's a very
clean mapping from svn onto git. If I ask about
/branches/whatever/myfile.c@SVN-NUMBER, it's different from asking
about "-r SVN-NUMBER /branches/whatever/myfile.c". The difference is
precisely what we're talking about representing here.
What's important is that they really are two totally unrelated
branches of history, which happen to have been referred to by the same
name at the time when they were current.
> The current use of @SVN-NUMBER in branches are only used when following
> parents (when repositories are rearranged). In retrospect, it's
> probably possible to for git-svn to not make them user-visible (I seem
> to recall they made development/debugging/testing easier in the past,
> though).
I wouldn't want to lose those names as they are now; they're
inconvenient, but important, because they accurately represent the
important points in svn history as it has been imported.
Have fun,
Avery
^ permalink raw reply
* Re: How to rebase for git svn?
From: Yang Zhang @ 2008-11-06 20:05 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: sverre, Eric Wong, git
In-Reply-To: <20081106102425.GA4192@atjola.homenet>
Björn Steinbrink wrote:
> On 2008.11.06 11:15:21 +0100, Sverre Rabbelier wrote:
>> On Thu, Nov 6, 2008 at 10:55, Eric Wong <normalperson@yhbt.net> wrote:
>>> Yang Zhang <yanghatespam@gmail.com> wrote:
>>>> Thanks in advance for any help!
>>> Try passing --rebase or --squash with "git pull" to keep history linear
>>> for SVN.
>> Consider doing the following:
>> git config alias.repull "pull --rebase"
>> And then using 'git repull' instead of 'git pull'.
>
> Or set branch.<name>.rebase in your config and just use "git pull" ;-)
> Setting branch.autosetuprebase might also be useful in that case.
>
> You should be careful to make sure that the other side does not lag
> behind WRT svn, though. Otherwise, you end up rebasing commits that
> corresponds to svn revisions. Bad.
>
> Björn
git pull --rebase doesn't seem to be working either....
http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1064&view=markup
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply
* Re: [RFC PATCH] gitweb: Support filtering projects by .htaccess files.
From: Alexander Gavrilov @ 2008-11-06 19:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <200811060026.59340.jnareb@gmail.com>
On Thursday 06 November 2008 02:26:58 Jakub Narebski wrote:
> Alexander Gavrilov wrote:
> > + For example, if you use mod_perl to run the script, and have dumb
> > + http protocol authentication configured for your repositories, you
> > + can use the following hook to allow access only if the user is
> > + authorized to read the files:
> > +
> > + $export_auth_hook = sub {
> > + use Apache2::SubRequest ();
> > + use Apache2::Const -compile => qw(HTTP_OK);
> > + my $path = "$_[0]/HEAD";
> > + my $r = Apache2::RequestUtil->request;
> > + my $sub = $r->lookup_file($path);
> > + return $sub->filename eq $path
> > + && $sub->status == Apache2::Const::HTTP_OK;
> > + };
>
> Can anybody check this? Or was it checked by author?
Well, it seems to do what is intended on my home server,
although it has a known limitation, so here is an updated
version that warns about it.
By the way, do you know how to deal with Apache or ModPerl's
urge to append standard error messages to the script output, other
than adding a bunch of lines like the following to the config?
ErrorMessage 400 " "
I couldn't find any solutions so far.
--- >8 ---
Subject: [PATCH] gitweb: Add a per-repository authorization hook.
Add a configuration variable that can be used to specify an
arbitrary subroutine that will be called in the same situations
where $export_ok is checked, and its return value will be used
to decide whether the repository is to be shown.
This allows the user to implement custom authentication
schemes, for example by issuing a subrequest through mod_perl
and checking if Apache will authorize it.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitweb/INSTALL | 23 +++++++++++++++++++++++
gitweb/gitweb.perl | 8 +++++++-
2 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 26967e2..72a1322 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -166,6 +166,29 @@ Gitweb repositories
shows repositories only if this file exists in its object database
(if directory has the magic file named $export_ok).
+- Finally, it is possible to specify an arbitrary perl subroutine that
+ will be called for each project to determine if it can be exported.
+ The subroutine receives an absolute path to the project as its only
+ parameter.
+
+ For example, if you use mod_perl to run the script, and have dumb
+ http protocol authentication configured for your repositories, you
+ can use the following hook to allow access only if the user is
+ authorized to read the files:
+
+ $export_auth_hook = sub {
+ use Apache2::SubRequest ();
+ use Apache2::Const -compile => qw(HTTP_OK);
+ my $path = "$_[0]/HEAD";
+ my $r = Apache2::RequestUtil->request;
+ my $sub = $r->lookup_file($path);
+ return $sub->filename eq $path
+ && $sub->status == Apache2::Const::HTTP_OK;
+ };
+
+ Note that since this sample works exclusively in the filesystem
+ namespace, <Location> sections of the configuration have no effect.
+
Generating projects list using gitweb
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 172ea6b..9329880 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -95,6 +95,11 @@ our $default_projects_order = "project";
# (only effective if this variable evaluates to true)
our $export_ok = "++GITWEB_EXPORT_OK++";
+# show repository only if this subroutine returns true
+# when given the path to the project, for example:
+# sub { return -e "$_[0]/git-daemon-export-ok"; }
+our $export_auth_hook = undef;
+
# only allow viewing of repositories also shown on the overview page
our $strict_export = "++GITWEB_STRICT_EXPORT++";
@@ -400,7 +405,8 @@ sub check_head_link {
sub check_export_ok {
my ($dir) = @_;
return (check_head_link($dir) &&
- (!$export_ok || -e "$dir/$export_ok"));
+ (!$export_ok || -e "$dir/$export_ok") &&
+ (!$export_auth_hook || $export_auth_hook->($dir)));
}
# process alternate names for backward compatibility
--
tg: (0d4f9de..) t/authenticate/hook (depends on: t/authenticate/unify-exportok)
^ permalink raw reply related
* Re: [PATCH 0/4] replace unsinged long with time_t
From: Linus Torvalds @ 2008-11-06 18:45 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <20081106183722.GL10996@eratosthenes.cryptobackpack.org>
On Thu, 6 Nov 2008, David Bryson wrote:
>
> I have always thought that time_t and similar were braindead, but hey
> the Janitor page listed it as desireable so what do I know ?
It might be worth it to make the internal git time always be 64-bit.
It was kind of a long-term plan anyway: git doesn't really ever have to
work with dates in the future (and things like "approxidate()" actually
know that and use it to guess what date you must be talking about), so
even a 32-bit "unsigned long" is expected to work well until 2038, but at
_some_ point we'd need to guarantee 64-bit epoch times.
It just wasn't something I was in a huge hurry over. Others have to worry
about dates from the future long before wrap-around, git really doesn't.
But from a janitorial standpoint, I certainly wouldn't totally hate using
a known 64-bit type for dates.
Linus
^ permalink raw reply
* Re: [PATCH 0/4] replace unsinged long with time_t
From: David Bryson @ 2008-11-06 18:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811061000430.3419@nehalem.linux-foundation.org>
Hi,
On Thu, Nov 06, 2008 at 10:13:46AM -0800 or thereabouts, Linus Torvalds wrote:
> So "time_t" really is a pretty damn worthless type. It's not _quite_ as
> broken as "socklen_t" (which is just a broken name for "int", and anybody
> who declares it to be anythign else is a total moron), but it's close.
I have always thought that time_t and similar were braindead, but hey
the Janitor page listed it as desireable so what do I know ?
> In theory, some platform might have a 64-but "unsigned long long" time_t
> even if the architecture is 32-bit (apparently windows used to do that if
> you included <time64.h>, for example), but since we wouldn't take
> advantage of that anyway, even then there is no real advantage.
Having a problem between 32 and 64 bit implementations does seem
undesireable.
http://git.or.cz/gitwiki/Janitor?action=info
Janitor wiki log says Pasky added the time_t conversion section. Care
to explain the reason for the request Pasky ?
Dave
^ permalink raw reply
* Re: [PATCH 0/4] replace unsinged long with time_t
From: Linus Torvalds @ 2008-11-06 18:13 UTC (permalink / raw)
To: David Bryson; +Cc: git
In-Reply-To: <1225993728-4779-1-git-send-email-david@statichacks.org>
On Thu, 6 Nov 2008, david@statichacks.org wrote:
>
> Here is a patch set from the Janitor page to replace unsigned long with time_t.
I actually don't much like this.
"time_t" is one of those totally broken unix types. The standards say that
it's an "arithmetic" type, but leaves it open to be just about anything.
Traditionally, it's a signed integer (bad), and in theory it could even be
a floating point value, I think.
And in _all_ such cases, it's actually better to cast it to "unsigned
long" than keep time in a system-dependent format that is most likely
either _already_ "unsigned long", or alternatively broken.
IOW, "unsigned long" is practically always either the same, or better
than, time_t. Do you actually have a platform where that isn't the case?
And we do end up casting it to "unsigned long" in the end anyway - the
date format in the commit is fundamentally not a signed one, and we use
"%lu" to print those things. Again, if we were to use "time_t", we'd now
have a huge and fundamental confusion about how to print them out, and
what to do if they were negative.
So "time_t" really is a pretty damn worthless type. It's not _quite_ as
broken as "socklen_t" (which is just a broken name for "int", and anybody
who declares it to be anythign else is a total moron), but it's close.
In theory, some platform might have a 64-but "unsigned long long" time_t
even if the architecture is 32-bit (apparently windows used to do that if
you included <time64.h>, for example), but since we wouldn't take
advantage of that anyway, even then there is no real advantage.
Linus
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Mark Burton @ 2008-11-06 17:53 UTC (permalink / raw)
To: git
In-Reply-To: <09C2A669-2B99-4490-9C95-FCCD76C03D61@idibu.com>
Hi Steve,
I think you are making the same mistake as I did when I first started using git.
You can't push to "master" from a remote repository because if you do, the index
and working files associated with the receiving repository look as if they have
been changed because they are out of date WRT the repository.
If you want to push to a repository that has working files associated with it,
push to a remote branch in that repository and then merge the contents of the
remote branch into the working files. I.e. don't push to "master", push to
"remotes/somename/master" and then merge somename/master into the master branch.
That's what I do now to migrate changes from my satellite development machines
to my master machine.
Cheers,
Mark
^ permalink raw reply
* [PATCH 1/4] Changed timestamps to time_t instead of unsigned
From: david @ 2008-11-06 17:48 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <1225993728-4779-1-git-send-email-david@statichacks.org>
From: David Bryson <david@statichacks.org>
---
builtin-prune.c | 2 +-
builtin-reflog.c | 8 ++++----
builtin-show-branch.c | 4 ++--
parse-options.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin-prune.c b/builtin-prune.c
index 7b4ec80..e1d46f0 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -12,7 +12,7 @@ static const char * const prune_usage[] = {
};
static int show_only;
static int verbose;
-static unsigned long expire;
+static time_t expire;
static int prune_tmp_object(const char *path, const char *filename)
{
diff --git a/builtin-reflog.c b/builtin-reflog.c
index 6b3667e..fdf78a9 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -27,8 +27,8 @@ struct cmd_reflog_expire_cb {
int rewrite;
int updateref;
int verbose;
- unsigned long expire_total;
- unsigned long expire_unreachable;
+ time_t expire_total;
+ time_t expire_unreachable;
int recno;
};
@@ -361,7 +361,7 @@ static struct reflog_expire_cfg *find_cfg_ent(const char *pattern, size_t len)
return ent;
}
-static int parse_expire_cfg_value(const char *var, const char *value, unsigned long *expire)
+static int parse_expire_cfg_value(const char *var, const char *value, time_t *expire)
{
if (!value)
return config_error_nonbool(var);
@@ -380,7 +380,7 @@ static int parse_expire_cfg_value(const char *var, const char *value, unsigned l
static int reflog_expire_config(const char *var, const char *value, void *cb)
{
const char *lastdot = strrchr(var, '.');
- unsigned long expire;
+ time_t expire;
int slot;
struct reflog_expire_cfg *ent;
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 306b850..73b3dc0 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -716,7 +716,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
base = strtoul(reflog_base, &ep, 10);
if (*ep) {
/* Ah, that is a date spec... */
- unsigned long at;
+ time_t at;
at = approxidate(reflog_base);
read_ref_at(ref, at, -1, sha1, NULL,
NULL, NULL, &base);
@@ -726,7 +726,7 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
for (i = 0; i < reflog; i++) {
char *logmsg, *m;
const char *msg;
- unsigned long timestamp;
+ time_t timestamp;
int tz;
if (read_ref_at(ref, 0, base+i, sha1, &logmsg,
diff --git a/parse-options.c b/parse-options.c
index fd08bb4..4581b50 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -480,7 +480,7 @@ int parse_opt_abbrev_cb(const struct option *opt, const char *arg, int unset)
int parse_opt_approxidate_cb(const struct option *opt, const char *arg,
int unset)
{
- *(unsigned long *)(opt->value) = approxidate(arg);
+ *(time_t *)(opt->value) = approxidate(arg);
return 0;
}
--
1.6.0.1
^ permalink raw reply related
* [PATCH 0/4] replace unsinged long with time_t
From: david @ 2008-11-06 17:48 UTC (permalink / raw)
To: git; +Cc: David Bryson
From: David Bryson <david@statichacks.org>
Here is a patch set from the Janitor page to replace unsigned long with time_t.
Since it overlaps slightly with a patch I made previously, I wrote this to
apply to next. Comments welcome.
David Bryson (4):
Changed timestamps to time_t instead of unsigned
Changed timestamps to time_t in header files
Changed timestamps to time_t instead of unsigned long for
approxidate()
Changed timestamps to time_t
builtin-gc.c | 2 +-
builtin-prune.c | 2 +-
builtin-reflog.c | 14 +++++++-------
builtin-show-branch.c | 4 ++--
cache.h | 2 +-
parse-options.c | 2 +-
refs.h | 2 +-
revision.h | 4 ++--
8 files changed, 16 insertions(+), 16 deletions(-)
^ permalink raw reply
* [PATCH 3/4] Changed timestamps to time_t instead of unsigned long for approxidate()
From: david @ 2008-11-06 17:48 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <1225993728-4779-3-git-send-email-david@statichacks.org>
From: David Bryson <david@statichacks.org>
---
builtin-gc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 7af65bb..168f484 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -58,7 +58,7 @@ static int gc_config(const char *var, const char *value, void *cb)
}
if (!strcmp(var, "gc.pruneexpire")) {
if (value && strcmp(value, "now")) {
- unsigned long now = approxidate("now");
+ time_t now = approxidate("now");
if (approxidate(value) >= now)
return error("Invalid %s: '%s'", var, value);
}
--
1.6.0.1
^ permalink raw reply related
* [PATCH 2/4] Changed timestamps to time_t in header files
From: david @ 2008-11-06 17:48 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <1225993728-4779-2-git-send-email-david@statichacks.org>
From: David Bryson <david@statichacks.org>
---
cache.h | 2 +-
refs.h | 2 +-
revision.h | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index a3c77f0..2c114f8 100644
--- a/cache.h
+++ b/cache.h
@@ -625,7 +625,7 @@ enum date_mode {
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
-unsigned long approxidate(const char *);
+time_t approxidate(const char *);
enum date_mode parse_date_format(const char *format);
#define IDENT_WARN_ON_NO_NAME 1
diff --git a/refs.h b/refs.h
index 06ad260..97c4bfe 100644
--- a/refs.h
+++ b/refs.h
@@ -55,7 +55,7 @@ extern void unlock_ref(struct ref_lock *lock);
extern int write_ref_sha1(struct ref_lock *lock, const unsigned char *sha1, const char *msg);
/** Reads log for the value of ref during at_time. **/
-extern int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *sha1, char **msg, unsigned long *cutoff_time, int *cutoff_tz, int *cutoff_cnt);
+extern int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *sha1, char **msg, time_t *cutoff_time, int *cutoff_tz, int *cutoff_cnt);
/* iterate over reflog entries */
typedef int each_reflog_ent_fn(unsigned char *osha1, unsigned char *nsha1, const char *, unsigned long, int, const char *, void *);
diff --git a/revision.h b/revision.h
index 2fdb2dd..7cc9dbd 100644
--- a/revision.h
+++ b/revision.h
@@ -103,8 +103,8 @@ struct rev_info {
/* special limits */
int skip_count;
int max_count;
- unsigned long max_age;
- unsigned long min_age;
+ time_t max_age;
+ time_t min_age;
/* diff info for patches and for paths limiting */
struct diff_options diffopt;
--
1.6.0.1
^ permalink raw reply related
* [PATCH 4/4] Changed timestamps to time_t
From: david @ 2008-11-06 17:48 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <1225993728-4779-4-git-send-email-david@statichacks.org>
From: David Bryson <david@statichacks.org>
Some static values and return codes from approxidate()
have now been changed from unsigned long to time_t
---
builtin-reflog.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-reflog.c b/builtin-reflog.c
index fdf78a9..f8ee25a 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -17,8 +17,8 @@ static const char reflog_expire_usage[] =
static const char reflog_delete_usage[] =
"git reflog delete [--verbose] [--dry-run] [--rewrite] [--updateref] <refs>...";
-static unsigned long default_reflog_expire;
-static unsigned long default_reflog_expire_unreachable;
+static time_t default_reflog_expire;
+static time_t default_reflog_expire_unreachable;
struct cmd_reflog_expire_cb {
struct rev_info revs;
@@ -462,7 +462,7 @@ static void set_reflog_expiry_param(struct cmd_reflog_expire_cb *cb, int slot, c
static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
{
struct cmd_reflog_expire_cb cb;
- unsigned long now = time(NULL);
+ time_t now = time(NULL);
int i, status, do_all;
int explicit_expiry = 0;
--
1.6.0.1
^ permalink raw reply related
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Isaac Jurado @ 2008-11-06 17:41 UTC (permalink / raw)
To: Marcin Kasperski; +Cc: mercurial, git
In-Reply-To: <878wrwom88.fsf@softax.com.pl>
On Thu, Nov 6, 2008 at 5:25 PM, Marcin Kasperski
<Marcin.Kasperski@softax.com.pl> wrote:
>
> Are really programming languages that important?
Considering the success of some of them, having the worst possible
syntax and semantics, I believe it does not matter much.
> Main showstoppers in this area are not the programming languages, but
> lack of documentation, miserable APIs, or lack of process. Or ... the
> fact that the tool is so good that it does not really need extensions.
I couldn't agree more. Sorry for such a useless reply, but I felt some
emotion reading "common sense".
Cheers.
--
Isaac Jurado Peinado
http://www.krenel.net
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
^ permalink raw reply
* [PATCH] Added test case for mirror to not push stash refs
From: david @ 2008-11-06 17:39 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <20081028212327.GA25358@sigill.intra.peff.net>
From: David Bryson <david@statichacks.org>
This test case checks to make sure mirror does not push stashed refs
---
t/t5517-push-mirror.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index ea49ded..bb263cd 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -123,6 +123,16 @@ test_expect_success 'push mirror adds, updates and removes branches together' '
'
+test_expect_success 'push mirror does not push stash refs' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo foo >foo && git add foo && git commit -m 'foo' &&
+ echo bar >foo && git stash save 'WIP' &&
+ git push --mirror up
+ )
+'
# TAG tests
test_expect_success 'push mirror creates new tags' '
--
1.6.0.1
^ permalink raw reply related
* Re: [PATCH (MINGW) Resend] Windows: Make OpenSSH properly detect tty detachment.
From: Johannes Sixt @ 2008-11-06 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Gavrilov, git
In-Reply-To: <7vvdv0iyl2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Do people build and test MinGW port out of my 'next'? If so, I'll queue
> this on its own topic branch and have it go through the usual "cook then
> graduate" cycle. Otherwise, I'll apply this directly on top of 'master'.
My own build is on top of your 'master', and I've cooked this patch to
death there already, so I don't think it needs another cycle. ;)
-- Hannes
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Steve Walker @ 2008-11-06 17:17 UTC (permalink / raw)
To: git
In-Reply-To: <334B3AB1-125A-4163-BEBC-9A73C4F569B5@idibu.com>
Sorry to keep answering my own questions directly after posting...
I just tried with a 'git commit -f' and the files updated.
Can anyone tell me if this is good practice? I would have thought a
normal commit would update from index to head - isnt always forcing it
creating potentially bad merges?
Kind regards, Steve.
On Nov 6, 2008, at 6:04 PM, Steve Walker wrote:
> Hi there,
>
> Hoping someone could point me in the right direction here.
>
> The overall issue is that with files that have been pushed into our
> repo on our server, when we then check out into local working copy
> the new files appear, but the updated files dont update even though
> the output suggests it has. The flow I'm doing:
>
> 1. The file I'm testing an update to is this:
>
> -rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
> test3.txt
>
> 2. On my local box I change file, add it, commit, then push it from
> my local box to our server repo:
>
> StevePoota:public_html steve$ vi steve-git-test3.txt
> StevePoota:public_html steve$ git add steve-git-test3.txt
> StevePoota:public_html steve$ git commit
> Created commit e29b724: testing only
> 1 files changed, 1 insertions(+), 0 deletions(-)
> StevePoota:public_html steve$ git push ssh://idibu.com/home/beta_idibu/public_html
> master:master
> Counting objects: 5, done.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 272 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To ssh://idibu.com/home/beta_idibu/public_html
> a28332a..e29b724 master -> master
>
> 3. It all looks good, on my server if i do a 'git log' I can see in
> the latest update:
>
> oneworld:/home/beta_idibu/public_html# git log
> commit e29b7246beab458d6a7b53cb245a5596adc8c198
> Author: Steve <steve@StevePoota.local>
> Date: Thu Nov 6 17:55:21 2008 +0100
>
> testing only
>
> 4. So I check out:
>
> oneworld:/home/beta_idibu/public_html# git checkout master
> M .gitignore
> M steve-git-test.txt
> M steve-git-test2.txt
> M steve-git-test3.txt
> Already on branch "master"
> oneworld:/home/beta_idibu/public_html#
>
> and its telling me that file has been modified
>
> but checking my file it hasnt changed by date stamp, and looking
> insie the file my changes arent there :((
>
> -rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
> test3.txt
>
> I'm stumped. I tried 777'ing that file temporarily in case git
> couldnt write to that file on checkout. What is strange is that when
> I add new files to the system it works - for example this file I'm
> testing no was originally added to the server via an external push.
>
> If anyone could give me some help I'd be very grateful.
>
> Kind regards, Steve.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
www.idibu.co.uk
steve@idibu.com
Sales: +44 (0)800 311 2750
Support: +44 (0)870 626 4268
Fax: +44 (0)8701 417 136
Mobile: +34 661 785 387
www.linkedin.com/in/stevejwalker
^ permalink raw reply
* Issue updating files during a checkout from a remote push
From: Steve Walker @ 2008-11-06 17:04 UTC (permalink / raw)
To: git
Hi there,
Hoping someone could point me in the right direction here.
The overall issue is that with files that have been pushed into our
repo on our server, when we then check out into local working copy the
new files appear, but the updated files dont update even though the
output suggests it has. The flow I'm doing:
1. The file I'm testing an update to is this:
-rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
test3.txt
2. On my local box I change file, add it, commit, then push it from my
local box to our server repo:
StevePoota:public_html steve$ vi steve-git-test3.txt
StevePoota:public_html steve$ git add steve-git-test3.txt
StevePoota:public_html steve$ git commit
Created commit e29b724: testing only
1 files changed, 1 insertions(+), 0 deletions(-)
StevePoota:public_html steve$ git push ssh://idibu.com/home/beta_idibu/public_html
master:master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 272 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://idibu.com/home/beta_idibu/public_html
a28332a..e29b724 master -> master
3. It all looks good, on my server if i do a 'git log' I can see in
the latest update:
oneworld:/home/beta_idibu/public_html# git log
commit e29b7246beab458d6a7b53cb245a5596adc8c198
Author: Steve <steve@StevePoota.local>
Date: Thu Nov 6 17:55:21 2008 +0100
testing only
4. So I check out:
oneworld:/home/beta_idibu/public_html# git checkout master
M .gitignore
M steve-git-test.txt
M steve-git-test2.txt
M steve-git-test3.txt
Already on branch "master"
oneworld:/home/beta_idibu/public_html#
and its telling me that file has been modified
but checking my file it hasnt changed by date stamp, and looking insie
the file my changes arent there :((
-rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
test3.txt
I'm stumped. I tried 777'ing that file temporarily in case git couldnt
write to that file on checkout. What is strange is that when I add new
files to the system it works - for example this file I'm testing no
was originally added to the server via an external push.
If anyone could give me some help I'd be very grateful.
Kind regards, Steve.
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Junio C Hamano @ 2008-11-06 17:06 UTC (permalink / raw)
To: Suraj N. Kurapati; +Cc: Jeff King, git
In-Reply-To: <200811060815.16797.sunaku@gmail.com>
"Suraj N. Kurapati" <sunaku@gmail.com> writes:
> On Thursday 06 November 2008 00:42:36 Jeff King wrote:
>> On Wed, Nov 05, 2008 at 09:59:25AM -0800, Suraj N. Kurapati wrote:
>> > Allows the user to answer 'Stage this hunk' questions with a
>> > single keypress, just like in Darcs. Previously, the user was
>> > forced to press the Return key after every choice they made.
>> > This quickly becomes tiring, burdensome work for the fingers.
>>
>> I think this is a reasonable goal, but I have a few questions/concerns.
>>
>> - There are three versions of your patch, but nobody has commented.
>> Clearly we can see what changed, but it is not clear what advantage
>> one patch has over the other. Care to elaborate?
>
> v1 and v2 make the mistake of setting raw mode, which prevent the user from
> pressing Control-C to exit the program. v3 fixes this by using cbreak mode.
When I was reading the last round I noticed the above change myself, but
it is customary to write this kind of "patch changelog" under --- line in
your patch around here. That way you can save everybody's time.
Thanks. And thanks, Jeff, for being a good reviewer.
^ permalink raw reply
* Re: [PATCH] Added test case for mirror to not push stash refs
From: Junio C Hamano @ 2008-11-06 16:58 UTC (permalink / raw)
To: sverre; +Cc: david, git
In-Reply-To: <bd6139dc0811060034q14e47232n5f00471e5420efbb@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
>> + git push --mirror up
>> + )
>> +'
>
> I don't quite get how this works, I don't see a test here anywhere to
> actually test that the stash refs were not pushed?
I agree that this test should check the receiving end.
The patch is relying on the fact that the receiving end would reject the
push if the sending end tries to push refs/$foo where $foo does not have
any slash.
^ permalink raw reply
* Re: [PATCH (MINGW) Resend] Windows: Make OpenSSH properly detect tty detachment.
From: Junio C Hamano @ 2008-11-06 16:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alexander Gavrilov, git
In-Reply-To: <49129E47.4080209@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> The latest "What's cooking in git.git" report still doesn't mention this
> patch. The reason might be ...
Sorry, my mistake.
>> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
>> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
>> ---
>>
>> This patch appears to have been overlooked,
Indeed. It was lost in the noise because it was marked MinGW and I failed
to see your Ack.
Do people build and test MinGW port out of my 'next'? If so, I'll queue
this on its own topic branch and have it go through the usual "cook then
graduate" cycle. Otherwise, I'll apply this directly on top of 'master'.
Thanks.
^ 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