* 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 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
* [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 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 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 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
* 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
* 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: [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: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: [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: 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: 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: [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: 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: 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
* 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: 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
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Brandon Casey @ 2008-11-06 23:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <GV8cY3fn8l5UV5cNoPN8bHchWt9u2tbZ8j_ypkiY-ZLfO1tx9d7ebA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Junio,
>
> Please leave this in pu for now, I have some concerns that I haven't
> had time to write down yet.
I've been thinking about pack-objects and repack.
Here's how I think the semantics of repack should be defined:
repack:
<no-options>
-incremental repack which does not repack any object currently packed
in any accessible pack.
Works (it currently works this way).
<-a>
-create a new pack containing all objects required by the repository
including those accessible through alternates, but excluding objects
in _local_ packs with .keep
Flawed, even with my recent patches.
If there are no local packs (or they all have .keep files), then the
pack-objects call will use --incremental which will exclude objects
packed in alt object store, even though -l was not used.
My patches do not differentiate local .keep files from remote .keep files,
which a user may have no control over.
<-A>
-Like -a, but local unreferenced objects which were previously packed
are made to be loose.
Ditto.
<-a -l>
-Restrict operation to only local objects. Only has any effect with -a|-A.
-Like -a, but additionally exclude objects in packs accessible through
alternates.
Works with my recent patches.
<-A -l>
-Like '-a -l', but loosen unreferenced local packed objects.
Ditto.
That set of repack operations needs to map to a combination of pack-objects
options:
<no-options>
-Create a pack with _all_ specified objects
<--unpacked>
-Exclude from packing any object already in an accessible pack.
(Ahh, this came from rev-list interface, and rejects objects at an
earlier stage than --incremental)
<--unpacked=sha1>
-Like '--unpacked', exclude already packed objects, but treat the objects
in the pack with specified sha1 as unpacked.
<--incremental>
-Exclude from packing any object already in an accessible pack,
regardless of whether it is in a pack specified by --unpacked=
(How is this different from --unpacked, even though the exclusion
operation is performed at a different stage? See my epiphany above
about the source of the --unpacked option)
<--unpacked --incremental>
-seems redundant, is there any functional difference?
<--local>
-Exclude objects from being packed that are not in the local object store.
The issue is how to provide my described 'repack -a' functionality.
There does not seem to be a mapping between the above options and the
required functionality.
I see two solutions, both require introducing a new option to pack-objects.
1) allow specifying a set of packs such that if an object resides
in any of the set, the object will not be included in the produced
pack.
Benefits:
-allows keeping pack-objects ignorant of .keep mechanism
-repack can easily be modified to produce the set of packs to ignore
Drawback:
-very round-about way just to have functionality to skip packs with
.keep file
2) New option telling pack-objects to skip objects in local .keep'd packs
Benefits:
-easy to implement in pack-objects
-easy to modify repack
Drawbacks:
-introduces new concept to pack-objects
Questions aside:
1) Are both --incremental and --unpacked still necessary pack-objects options?
2) Can --incremental become an alias for --unpacked, and go away?
patch(es) will follow.
-brandon
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Junio C Hamano @ 2008-11-07 0:30 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <HBFmgmcvgPzZ0xq-fRUt98ZOBXGCvwxHGyEwF9bNcgpDgS-t-D3viw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> <-a>
> -create a new pack containing all objects required by the repository
> including those accessible through alternates, but excluding objects
> in _local_ packs with .keep
I have a feeling that it is debatable if this "fattening to dissociate
from alternates" is what people want.
> <-a -l>
> -Restrict operation to only local objects. Only has any effect with -a|-A.
> -Like -a, but additionally exclude objects in packs accessible through
> alternates.
Presumably you meant "exclude objects accessible through alternates,
either in packs or in loose form"? If so then I think it is a good thing
to have.
I am not sure if listing the behaviour by combination of flags is a good
way to start thinking about this. Wouldn't it be more productive to list
what kinds of repacking are needed, and then label them with combination
of flags? Otherwise you would miss a potentially useful operation that
cannot be expressed with the current set of flags you have.
I think the useful kinds are only these five:
- scoop loose objects that exist in local repository into a new pack,
without touching existing packs at all; exclude anything available in
any existing pack or in alternate repository (either loose or packed);
- pack everything that is needed by the local ref, except the ones that
are borrowed from alternate repositories (either loose or packed), into
a single new pack. There are two variants of this: eject what is
currently packed but unnecessary into loose format when existing local
packs are replaced with the new pack, or lose them (i.e. -A).
- fatten local repository by packing everything that is needed by the
local ref into a single new pack, including things that are currently
borrowed from alternates. There are two variants of this: eject what
is currently packed but unnecessary into loose format when existing
local packs are replaced with the new pack, or lose them (i.e. -A).
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Jakub Narebski @ 2008-11-07 0:34 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811061313.50711.fg@one2team.net>
On Thu, 6 Nov 2008, Francis Galiegue wrote:
> Le Thursday 06 November 2008 04:08:16 Jakub Narebski, vous avez écrit :
> Hello,
> [...]
> > >
> > > * 52 CVS modules, fine; but then this can become one and 52
> > > subdirectories in them and still act as separate modules from
> > > the build system point of view (which I have implemented, so
> > > I can change it);
> >
> > I think that those CVS modules should become separate repositories,
> > perhaps joined together using submodules. This is one of more
> > difficult things during conversion.
> >
> > Note that in Git commits are always whole tree (whole project)
> > commits.
> >
>
> Honestly, I'm not fond of this approach. The problem with submodules as far as
> I'm concerned is that documentation is "not really there", and (unless the
> README of egit is _really_ outdated) that there's no support in egit.
>
> I know about commits affecting the whole tree, and even branches and tags, and
> that's more of an advantage to my eyes, for two reasons:
>
> * 99+% of queries currently done on the CVS tree (with Bonsai) cover all
> modules; only rarely is a single module concerned, and in this case you just
> fill in the appropriate field in the search page anyway;
Well, the mapping of CVS modules into Git repositories, and perhaps
also later binding those Git repositories together using submodules
support is IMHO one of more difficult decisions when deciding on
migration from CVS to Git.
What you would have to ask yourself is which of those CVS modules
are independent, for example having independent version numbers (tags)
and independent branches. And if commit really affects whole tree...
> * creating a branch is one command and that's it. It may also be one command
> with submodules, but again, the documentation makes me uncomfortable; with
> CVS, well... You get the picture.
Submodules are Git repositories of their own. So you have branching
there (almost) as easy as otherwise in Git. The only problem is a bit
lacking UI for binding those submodules together.
>
> What's more, I don't think we have the requirement of making specific
> per-module tags. Not as far as this has been discussed so far, anyway, and
> not as far as the history shows.
Well, that is one issue that would help in mapping CVS modules to Git
repositories (and submodules).
>
> > > * second: even though this may be a "non problem", we use Bonsai,
> > > which has the ability to see what was commited by whom, given a time
> > > interval (from d1 to d2): the base gitweb allows to search by
> > > commiter, which is good, but it has no date boundaries: do tools
> > > exist for git that can do this? If not, that wouldn't be a big deal,
> > > however...
> >
> > First, there are more web interfaces than gitweb, see
> > http://git.or.cz/gitweb/InterfacesFrontendsAndTools
>
> Yep, I've yet to try those... There are quite a few!
>
> > Second, you can do this from command line, using combination of commit
> > limiting a..b and a...b, or --since=<date> or --after=<date> and
> > --before=<date>, commit message searching --author, --committer, and
> > --grep, and path limiting "git log -- <pathspec>".
>
> Well, a Web-based search engine is kind of a requirement. I'm the only one to
> do command line... Thanks for the hints, though!
You can also use one of GUI; qgit and gitk + git-gui seems to be quite
mature and cross-platform.
> > Third, it would be not that hard to add more advanced search support
> > to gitweb; this is even one of planned features.
I think there are two possible ways of doing it: have a kind of
"advanced search" form, where one can have fill search terms, like
date limit, path limiting etc; or have an option to limit search to
current view context (for example current file or current directory).
> Which brings back to the subject of submodules, since as I said above, we
> generally search on the entire tree, and per-module searches are rare.
Hmmm...
>
> > > * third: also Bonsai-related; Bonsai can link to Bugzilla by
> > > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> > > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> > > this built-in? (haven't looked yet) Is this planned, or has it been
> > > discussed and been considered not worth the hassle?
> >
> > This is (under name of 'committags') in gitweb TODO; gitweb-xmms2
> > support this IIRC or supported this (for Mantis and not Bugzilla
> > though...)
>
> Interesting... I'll have a look at it.
Well, now I have bumped priority of this item in my gitweb TODO list...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/3] Introduce rename factorization in diffcore.
From: Junio C Hamano @ 2008-11-07 1:10 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081101220319.1116.50509.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> Rename factorization tries to group together files moving from and to
> identical directories - the most common case being directory renames.
> We do that by first identifying groups of bulk-moved files, and then
> hiding those of the individual renames which carry no other
> information (further name change, or content changes).
> This feature is activated by the new --factorize-renames diffcore
> flag.
I have a mixed feeling about this one, primarily because I cannot
visualize how a useful output should look like. Unless you rename one
directory to another without any content changes, you would have to say
"this directory changed to that, and among the paths underneath them, this
file have this content change in addition".
A related feature that would benefit from something like your change
without any downside/complication of output format issues is to boost
rename similarity score of a path when its neighbouring paths are moved to
the same location. E.g. when you see:
- three files a/{1,2,3} deleted;
- three files b/{1,2,3} created;
- (a/1 => b/1) and (a/2 => b/2) are similar enough;
- (a/3 => b/3) are not similar enough.
we currently detect only two renames and leave deletion of a/3 and
creation of b/3 unpaired. You should be able to help them paired up by
noticing that the entire a/* goes away (for that, reading the full
postimage like you do in your patch helps) and boost the similarity score
between these two.
Although I do not offhand think a good format to show the information you
are trying to capture in the textual diff output, one thing that would be
helped by the grouping of renames like you do would be process_renames()
in merge_recursive.c. This is especially so when you have added a new
path in a directory that has been moved by the other branch you are
merging. For this usage, there is no "textual output format" issues. It
does not even have to be expressed by replacing individual entries from
diffq with entries that represent a whole subtree --- you could for
example keep what diffq.queue records intact, and add a separate list of
directory renames as a hint for users like process_renames() to use.
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Brandon Casey @ 2008-11-07 1:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <7v8wrwidi3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> <-a>
>> -create a new pack containing all objects required by the repository
>> including those accessible through alternates, but excluding objects
>> in _local_ packs with .keep
>
> I have a feeling that it is debatable if this "fattening to dissociate
> from alternates" is what people want.
I'm not sure I understand you here.
Andreas has suggested previously that 'repack -a' should pack everything,
including objects in packs with .keep. Is that what you mean?
With my current understanding it seems that that would muddy the semantics
of repack. If -a does not honor packs with .keep, then would it be intuitive
to expect that adding -l (i.e. exclude alternate packed objects) _would_
honor .keep?
>> <-a -l>
>> -Restrict operation to only local objects. Only has any effect with -a|-A.
>> -Like -a, but additionally exclude objects in packs accessible through
>> alternates.
>
> Presumably you meant "exclude objects accessible through alternates,
> either in packs or in loose form"? If so then I think it is a good thing
> to have.
Would that be an enhancement to the current behavior? I don't think I saw
any mechanism to exclude packing remote loose objects.
The documentation for pack-objects --local says:
--local
This flag is similar to --incremental; instead of ignoring all
packed objects, it only ignores objects that are packed and not
in the local object store (i.e. borrowed from an alternate).
It only mentions packed alternate objects.
>
> I am not sure if listing the behaviour by combination of flags is a good
> way to start thinking about this. Wouldn't it be more productive to list
> what kinds of repacking are needed, and then label them with combination
> of flags? Otherwise you would miss a potentially useful operation that
> cannot be expressed with the current set of flags you have.
I agree. I made a list of the options because I was trying to understand what
effect each option had, then I turned it into an email.
> I think the useful kinds are only these five:
>
> - scoop loose objects that exist in local repository into a new pack,
> without touching existing packs at all; exclude anything available in
> any existing pack or in alternate repository (either loose or packed);
>
> - pack everything that is needed by the local ref, except the ones that
> are borrowed from alternate repositories (either loose or packed), into
> a single new pack. There are two variants of this: eject what is
> currently packed but unnecessary into loose format when existing local
> packs are replaced with the new pack, or lose them (i.e. -A).
>
> - fatten local repository by packing everything that is needed by the
> local ref into a single new pack, including things that are currently
> borrowed from alternates. There are two variants of this: eject what
> is currently packed but unnecessary into loose format when existing
> local packs are replaced with the new pack, or lose them (i.e. -A).
You didn't say when local .keep should be honored, i.e. objects in local
packs with .keep should be excluded from repacking. always, never, only
with -l, new repack option?
-brandon
^ permalink raw reply
* [PATCH 1/4] pack-objects: new option --honor-pack-keep
From: Brandon Casey @ 2008-11-07 1:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <HBFmgmcvgPzZ0xq-fRUt98ZOBXGCvwxHGyEwF9bNcgpDgS-t-D3viw@cipher.nrlssc.navy.mil>
This adds a new option to pack-objects which will cause it to ignore an
object which appears in a local pack which has a .keep file, even if it
was specified for packing.
This option will be used by the porcelain repack.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This series replaces the previous series starting at
6ee726bc "pack-objects: honor '.keep' files"
It should be applied on top of
f34cf12d "packed_git: convert pack_local flag into a bitfield and add pack_keep"
I created the series on top of f34cf12d rebased on top of master.
Suggestions for a more appropriate name for --honor-pack-keep are very welcome.
-brandon
Documentation/git-pack-objects.txt | 5 +++++
builtin-pack-objects.c | 7 +++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 8c354bd..f9fac2c 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -109,6 +109,11 @@ base-name::
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
+--honor-pack-keep::
+ This flag causes an object already in a local pack that
+ has a .keep file to be ignored, even if it appears in the
+ standard input.
+
--incremental::
This flag causes an object already in a pack ignored
even if it appears in the standard input.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 15b80db..ddec341 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -71,6 +71,7 @@ static int reuse_delta = 1, reuse_object = 1;
static int keep_unreachable, unpack_unreachable, include_tag;
static int local;
static int incremental;
+static int ignore_packed_keep;
static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
@@ -703,6 +704,8 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
return 0;
if (local && !p->pack_local)
return 0;
+ if (ignore_packed_keep && p->pack_local && p->pack_keep)
+ return 0;
}
}
@@ -2048,6 +2051,10 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
incremental = 1;
continue;
}
+ if (!strcmp("--honor-pack-keep", arg)) {
+ ignore_packed_keep = 1;
+ continue;
+ }
if (!prefixcmp(arg, "--compression=")) {
char *end;
int level = strtoul(arg+14, &end, 0);
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 2/4] repack: don't repack local objects in packs with .keep file
From: Brandon Casey @ 2008-11-07 1:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <oDevG_2ETMLvy6rfSqvxfmFqABeVqlDUcU6FjP07E5IzqLaopWkQbQ@cipher.nrlssc.navy.mil>
If the user created a .keep file for a local pack, then it can be inferred
that the user does not want those objects repacked.
This fixes the repack bug tested by t7700.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 2 +-
t/t7700-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index d39eb6c..8bb2201 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -83,7 +83,7 @@ case ",$all_into_one," in
esac
args="$args $local $quiet $no_reuse$extra"
-names=$(git pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git pack-objects --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$names" ]; then
if test -z "$quiet"; then
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 7aaff0b..356afe3 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -4,7 +4,7 @@ test_description='git repack works correctly'
. ./test-lib.sh
-test_expect_failure 'objects in packs marked .keep are not repacked' '
+test_expect_success 'objects in packs marked .keep are not repacked' '
echo content1 > file1 &&
echo content2 > file2 &&
git add . &&
--
1.6.0.3.552.g12334
^ permalink raw reply related
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