* Re: Git {log,diff} against tracked branch?
From: Petr Baudis @ 2009-03-18 18:26 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <200903181448.50706.agruen@suse.de>
Hi,
On Wed, Mar 18, 2009 at 02:48:50PM +0100, Andreas Gruenbacher wrote:
> I often want to see what the differences are between a local branch and the
> branch it tracks (if it tracks a branch). I currently do something like "git
> log master..origin/master". This is a lot of unnecessary typing though
> compared to something like "git log -t master", or even "git log -t" when on
> the master branch.
sorry, I think Git can't do anything like this either. :-(
However, I think something like this would be useful and probably easy
to do? Maybe someone on the list will get inspired to implement
a special refspec character to represent the "tracked branch"
relationship, so e.g. %master would expand to %origin/master. Then you
should be able to do something like:
git log %..
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Junio C Hamano @ 2009-03-18 18:22 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Haggerty, ydirson, git
In-Reply-To: <49C13062.4020400@hvoigt.net>
Heiko Voigt <git-list@hvoigt.net> writes:
> This is an updated version of the first patch and an addition to ensure
> correct handling of branches in fixes.
I've already merged the first one to 'next' so this needs to be turned
into an incremental update if we were to continue building on top in the
git project.
I however have a bigger issue with this, perhaps because I do not have the
feeling that I fully understand where these patches are going.
Your approach seems to me to:
- add tests to git test suite that expose issues the current cvsimport
that runs on an unpatched cvsps has;
- diagnose and fix
- the issues in cvsimport, if the problem is because cvsimport is
mishandling correct output from cvsps; or
- the issues in cvsps (and adjust cvsimport to patched cvsps if
necessary), if the problem is because output from cvsps is incorrect.
That all feels sane, and having the tests to verify the end result would
help the people who collaborate on these tasks.
But how much of the actual fix will be made to cvsps, and how much to
cvsimport? If the majority of the changes are to happen on cvsps (which
is not unexpected, given that many people who tried and wrote various cvs
importers put blame on the shortcomings of its output), I am afraid that
it would not help majority of git users until the fixes to cvsps that come
out of this effort hit their distros for me to keep these tests in the
git.git repository. I do not build and install custom cvsps (because I
haven't had to work with complex history in CVS that your improvements to
cvsps are need to deal with correctly), and I suspect many others are in
the same boat. In addition, if your tests are in the git.git repository,
they need to say test_expect_success for people with patched cvsps and
test_expect_failure for people without, and because I suspect that the
majority of git developers do not run bleeding edge cvsps, it does not do
anything but slowing down the test suite.
It feels as if you are scratching my feet through my shoes while I still
am wearing them. I wonder if it would be more direct and simpler approach
to add tests to cvsps and handle these improvements as part of the cvsps
maintenance/development effort, not as part of cvsimport fixes, at least
initially.
I think it is great that you started actively working on identifying and
fixing issues with cvsps, that many others have gave up and gone to
different avenues, and I certainly do not mind keeping the new tests in
'pu' for wider exposure, in order to make it easier for other people who
use cvsimport and want to collaborate with you improving it through
improving cvsps.
But I am starting to think that it was a mistake on my part to have merged
the initial set of tests to 'next'.
Thoughts?
^ permalink raw reply
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Nicolas Pitre @ 2009-03-18 18:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0903181657180.10279@pacific.mpi-cbg.de>
On Wed, 18 Mar 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 6 Dec 2007, Johannes Schindelin wrote:
>
> >
> > The default was not to change the window or depth at all. As suggested
> > by Jon Smirl, Linus Torvalds and others, default to
> >
> > --window=250 --depth=250
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
>
> Guess what. This is still unresolved, and yet somebody else had to be
> bitten by 'git gc --aggressive' being everything but aggressive.
>
> So... I think it is high time to resolve the issue, either by applying
> this patch with a delay of over one year, or by the pack wizards trying to
> implement that 'never fall back to a worse delta' idea mentioned in this
> thread.
This is just a bit complicated to implement (cycle avoidance, etc).
> Although I suggest, really, that implying --depth=250 --window=250 (unless
> overridden by the config) with --aggressive is not at all wrong.
ACK.
Nicolas
^ permalink raw reply
* [JGIT PATCH 2/2] Micro-optimize the merge base generator
From: Shawn O. Pearce @ 2009-03-18 18:01 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1237399309-29493-1-git-send-email-spearce@spearce.org>
Instead of doing 3 bit-wise and operations followed by 3 compares
and two boolean and conditions on every commit we evaluate in the
history, we can fold all of the tests into a pair of fields and
do one bit mask and compare.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/revwalk/MergeBaseGenerator.java | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java
index 2eb9688..8694e4c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java
@@ -73,6 +73,10 @@
private int branchMask;
+ private int recarryTest;
+
+ private int recarryMask;
+
MergeBaseGenerator(final RevWalk w) {
walker = w;
pending = new DateRevQueue();
@@ -91,6 +95,12 @@ void init(final AbstractRevQueue p) {
// will be available for reuse when the walk resets.
//
walker.freeFlag(branchMask);
+
+ // Setup the condition used by carryOntoOne to detect a late
+ // merge base and produce it on the next round.
+ //
+ recarryTest = branchMask | POPPED;
+ recarryMask = branchMask | POPPED | MERGE_BASE;
}
}
@@ -187,8 +197,7 @@ private boolean carryOntoOne(final RevCommit p, final int carry) {
final boolean haveAll = (p.flags & carry) == carry;
p.flags |= carry;
- if ((p.flags & POPPED) != 0 && (carry & MERGE_BASE) == 0
- && (p.flags & branchMask) == branchMask) {
+ if ((p.flags & recarryMask) == recarryTest) {
// We were popped without being a merge base, but we just got
// voted to be one. Inject ourselves back at the front of the
// pending queue and tell all of our ancestors they are within
--
1.6.2.1.337.g6270ba
^ permalink raw reply related
* [JGIT PATCH 1/2] Fix long running merge base computations
From: Shawn O. Pearce @ 2009-03-18 18:01 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
If a part of the project history is reachable by more than one
path through the revision graph, we only need to traverse down
it once through the first detected path when marking parents
as reachable from an input branch.
Previously, JGit recomputed the entire project history for each
path it was reachable through. On linux-2.6 based histories we
got stuck for hours computing a merge base, as we kept passing
back through the same sections of the revision graph.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/revwalk/MergeBaseGenerator.java | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java
index 1676caa..2eb9688 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/MergeBaseGenerator.java
@@ -184,7 +184,9 @@ private void carryOntoHistory(RevCommit c, final int carry) {
}
private boolean carryOntoOne(final RevCommit p, final int carry) {
+ final boolean haveAll = (p.flags & carry) == carry;
p.flags |= carry;
+
if ((p.flags & POPPED) != 0 && (carry & MERGE_BASE) == 0
&& (p.flags & branchMask) == branchMask) {
// We were popped without being a merge base, but we just got
@@ -197,6 +199,11 @@ private boolean carryOntoOne(final RevCommit p, final int carry) {
carryOntoHistory(p, branchMask | MERGE_BASE);
return true;
}
- return false;
+
+ // If we already had all carried flags, our parents do too.
+ // Return true to stop the caller from running down this leg
+ // of the revision graph any further.
+ //
+ return haveAll;
}
}
--
1.6.2.1.337.g6270ba
^ permalink raw reply related
* [PATCH 3/3] rebase: add options passed to git-am
From: Michele Ballabio @ 2009-03-18 18:05 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1237399558-27289-1-git-send-email-barra_cuda@katamail.com>
Add the options --committer-date-is-author-date and --ignore-date
to git-rebase. They were introduced in commit a79ec62d0 for git-am.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
I'm not sure if force_rebase should be set in this case.
Documentation/git-rebase.txt | 5 +++++
git-rebase.sh | 3 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 6cb902a..457340c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -269,6 +269,11 @@ OPTIONS
(see linkgit:git-apply[1]) that applies the patch.
Incompatible with the --interactive option.
+--committer-date-is-author-date::
+--ignore-date::
+ These flags are passed to 'git-am' to easily change the dates
+ of the rebased commits (see linkgit:git-am[1]).
+
-i::
--interactive::
Make a list of the commits which are about to be rebased. Let the
diff --git a/git-rebase.sh b/git-rebase.sh
index e38d68a..d89d71c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -309,6 +309,9 @@ do
;;
esac
;;
+ --committer-date-is-author-date|--ignore-date)
+ git_am_opt="$git_am_opt $1"
+ ;;
-C*)
git_am_opt="$git_am_opt $1"
;;
--
1.6.2.22.gc2ac
^ permalink raw reply related
* [PATCH] git log: avoid segfault with --all-match
From: Michele Ballabio @ 2009-03-18 18:06 UTC (permalink / raw)
To: git; +Cc: gitster
Avoid a segfault when the command
git log --all-match
was issued.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Not sure if this is the right fix, nor if it would be better a
warning or an error.
grep.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/grep.c b/grep.c
index 062b2b6..cb4666d 100644
--- a/grep.c
+++ b/grep.c
@@ -190,7 +190,8 @@ void compile_grep_patterns(struct grep_opt *opt)
* A classic recursive descent parser would do.
*/
p = opt->pattern_list;
- opt->pattern_expression = compile_pattern_expr(&p);
+ if (p)
+ opt->pattern_expression = compile_pattern_expr(&p);
if (p)
die("incomplete pattern expression: %s", p->pattern);
}
--
1.6.2.22.gc2ac
^ permalink raw reply related
* [PATCH 2/3] document --force-rebase
From: Michele Ballabio @ 2009-03-18 18:05 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1237399558-27289-1-git-send-email-barra_cuda@katamail.com>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Documentation/git-rebase.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 57bd333..6cb902a 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -258,6 +258,12 @@ OPTIONS
context exist they all must match. By default no context is
ever ignored.
+-f::
+--force-rebase::
+ Force the rebase even if the current branch is up to date.
+ Normally, if the current branch is up to date, the rebase is
+ aborted.
+
--whitespace=<option>::
This flag is passed to the 'git-apply' program
(see linkgit:git-apply[1]) that applies the patch.
--
1.6.2.22.gc2ac
^ permalink raw reply related
* [PATCH 1/3] rebase: fix typo (force_rebas -> force-rebas)
From: Michele Ballabio @ 2009-03-18 18:05 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index d38ab0b..e38d68a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -315,7 +315,7 @@ do
--root)
rebase_root=t
;;
- -f|--f|--fo|--for|--forc|force|--force-r|--force-re|--force-reb|--force-reba|--force_rebas|--force-rebase)
+ -f|--f|--fo|--for|--forc|force|--force-r|--force-re|--force-reb|--force-reba|--force-rebas|--force-rebase)
force_rebase=t
;;
-*)
--
1.6.2.22.gc2ac
^ permalink raw reply related
* [PATCH 1/2] apply: consistent spelling of "don't"
From: Michele Ballabio @ 2009-03-18 18:05 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index f312798..a664338 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -3212,7 +3212,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
struct option builtin_apply_options[] = {
{ OPTION_CALLBACK, 0, "exclude", NULL, "path",
- "don´t apply changes matching the given path",
+ "don't apply changes matching the given path",
0, option_parse_exclude },
{ OPTION_CALLBACK, 0, "include", NULL, "path",
"apply changes matching the given path",
--
1.6.2.22.gc2ac
^ permalink raw reply related
* [PATCH 2/2] apply: hide unused options from short help
From: Michele Ballabio @ 2009-03-18 18:05 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1237399540-27258-1-git-send-email-barra_cuda@katamail.com>
The options "--binary" and "--allow-binary-replacement" of
git-apply are no-op and maintained for backward compatibility,
so avoid to show them in the short help screen.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-apply.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index a664338..0e8e5ae 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -3224,10 +3224,10 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
"ignore additions made by the patch"),
OPT_BOOLEAN(0, "stat", &diffstat,
"instead of applying the patch, output diffstat for the input"),
- OPT_BOOLEAN(0, "allow-binary-replacement", &binary,
- "now no-op"),
- OPT_BOOLEAN(0, "binary", &binary,
- "now no-op"),
+ { OPTION_BOOLEAN, 0, "allow-binary-replacement", &binary,
+ NULL, "old option, now no-op", PARSE_OPT_HIDDEN },
+ { OPTION_BOOLEAN, 0, "binary", &binary,
+ NULL, "old option, now no-op", PARSE_OPT_HIDDEN },
OPT_BOOLEAN(0, "numstat", &numstat,
"shows number of added and deleted lines in decimal notation"),
OPT_BOOLEAN(0, "summary", &summary,
--
1.6.2.22.gc2ac
^ permalink raw reply related
* [PATCH] format-patch: Respect --quiet option
From: Nate Case @ 2009-03-18 17:00 UTC (permalink / raw)
To: git, gitster; +Cc: Nate Case
Hide the patch filename output from 'git format-patch' when --quiet
is used. The man pages suggested that this should have already worked.
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
builtin-log.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 8684fcd..8af55d2 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -573,7 +573,7 @@ static FILE *realstdout = NULL;
static const char *output_directory = NULL;
static int outdir_offset;
-static int reopen_stdout(const char *oneline, int nr, int total)
+static int reopen_stdout(const char *oneline, int nr, struct rev_info *rev)
{
char filename[PATH_MAX];
int len = 0;
@@ -598,7 +598,9 @@ static int reopen_stdout(const char *oneline, int nr, int total)
strcpy(filename + len, fmt_patch_suffix);
}
- fprintf(realstdout, "%s\n", filename + outdir_offset);
+ if (!DIFF_OPT_TST(&rev->diffopt, QUIET))
+ fprintf(realstdout, "%s\n", filename + outdir_offset);
+
if (freopen(filename, "w", stdout) == NULL)
return error("Cannot open patch file %s",filename);
@@ -687,7 +689,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
die("Cover letter needs email format");
if (!use_stdout && reopen_stdout(numbered_files ?
- NULL : "cover-letter", 0, rev->total))
+ NULL : "cover-letter", 0, rev))
return;
head_sha1 = sha1_to_hex(head->object.sha1);
@@ -1106,7 +1108,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
}
if (!use_stdout && reopen_stdout(numbered_files ? NULL :
get_oneline_for_filename(commit, keep_subject),
- rev.nr, rev.total))
+ rev.nr, &rev))
die("Failed to create output files");
shown = log_tree_commit(&rev, commit);
free(commit->buffer);
--
1.6.0.2
^ permalink raw reply related
* [CVSPS PATCH v2] fix: correct rev order in case commiters clocks were not syncronised
From: Heiko Voigt @ 2009-03-18 17:34 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, ydirson, git
In-Reply-To: <49B52F74.1090006@alum.mit.edu>
This fixes the following kind of cvs issues:
Structure of the test cvs repository
Message File:Content Commit Time
Rev 1 a: 1.1 2009-02-21 19:11:43 +0100
Rev 2 a: 1.2 b: 1.1 2009-02-21 19:11:14 +0100
Rev 3 b: 1.2 2009-02-21 19:11:43 +0100
As you can see the commit of Rev 3 has the same time as
Rev 1 this was leading to a broken estimation of patchset
order.
The correction only applies to the main development line and specifically
ignores branches. The reason behind this is that a complete implementation
covering the correction of branches needs much more work.
I do not consider this patch a very "clean" bugfix. It is somewhat hacky
but may help someone who otherwise would not be able to use cvsps. It
additionally can help to find broken revisions and manually correct the
input files.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
I am currently looking into a more clean solution which does not fidle
with the timestamps but only corrects the ordering of patchsets. To
implement this cvsps needs to be extended to use a topological sort
algorithm instead of a simple merge sort. Maybe Michael can give me some
directions how this was solved in cvs2svn.
My current idea is about using a modified selection sort. Sorting in
chronological order. It should always select the minimum date as the
next patchset as long as it does not conflict with the minimum last
chosen revision of all affected files. If it conflicts another pass will
select the patchset with the minimum revision for that file. This means
sorting time will be O(n^2), another drawback is the space required to
remember the last revision of every file and its branches.
Assuming that this can be implemented in my limited time I will attempt
to do so.
Here are a few explanations about this updated patch:
Michael Haggerty schrieb:
>
> I am not familiar with the cvsps code, so I will just make some comments
> about things that it is not obvious from your patch that you have
> considered. These things all caused problems in pre-2.0 versions of
> cvs2svn:
>
> 1. It is not clear from the patch in what order the revisions are being
> processed. If they are being processed in the order that they appear in
> the RCS file, then you have to consider branches:
>
> * The date adjustment should only occur along chains of revisions
> that are "causally related" -- that is, adjacent revisions on trunk, or
> adjacent revisions on a branch, or the first revision on a branch
> relative to the revision from which the branch sprouted. It is not
> always the case that revisions that are adjacent in the RCS file are
> causally related.
>
> * The revisions along trunk appear in RCS files in reverse
> chronological order; e.g., 1.3, 1.2, 1.1 (this seems to be the case you
> handle). But the revisions along a branch appear in chronological
> order; e.g., 1.3.2.1, 1.3.2.2, 1.3.2.3. Do you handle both cases
> correctly? (A unit test involving revisions on branches would be helpful.)
The input which is parsed by cvsps comes from the cvs log command. There
everything appears in reverse chronological order. Branches always come
at the end of the log so they are not timely ordered among the main
development line.
I adressed this issue by only applying the correction to the mainline.
This is not complete but solves the most practical special case.
A complete implementation needs much more work because in addition to
the last revision of the main line the last revision of every branch
would need to be remembered.
> 2. One form of clock skew that is common in CVS repositories is that
> some computer's CMOS battery went dead and the clock reverted to 1970
> after every reboot. Given that you adjust revisions' times only towards
> the past, then such a glitch would force the times of all earlier
> revisions to be pushed back to 1970. (Since you unconditionally
> subtract one second from each commit timestamp, this could also
> conceivably cause an underflow to 2038, but this is admittedly rather
> unlikely.) This is a hard problem to solve generally. But if you want
> to handle this problem more robustly, I suggest that you always adjust
> times towards the future, as incorrect clock times in the far future
> seem to be less common in practice.
>
> Of course these clock skew corrections, if only applied to one file at a
> time, can easily cause changesets to be broken up if the time deltas
> exceed five minutes.
I addressed this by checking for time_t underflow before correction.
cvps will exit with an error message in case it happens. Due to the
reverse chronological order of the input I am only able to see one step
into the future but not into the past. Thats why I can only correct into
the past.
>
> 3. When cvsps collects individual file revisions into changesets (within
> the 5 minute window), a single "consensus" commit time has to be chosen
> from all of the single-file commits. Depending on how cvsps does this,
> it could be that the consensus commit times for two commits involving
> revisions within a single file are put back out of order (undoing your
> timestamp fixup). It would be nice to verify that this does not result
> in out-of-order commits.
On file revisions cvsps corrects using this patch it will probably
happen that one change is broken into multiple patchsets. Because cvsps
issues warnings for every revision time it is changing the user can
manually repair these rcs files.
cvsps keeps the minimum time of any member as the "consensus" time. So
the time correction backwards in time can result in out of order
commits. So it is not ensured that all commits compile. But it should be
ensured that all revisions of single files appear in the correct order.
As stated in the commit message this is not a "clean" solution but can
help to clean the imported repository and get correct revision ordering
on the main development line.
cvsps.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/cvsps.c b/cvsps.c
index 81c6e21..1e72969 100644
--- a/cvsps.c
+++ b/cvsps.c
@@ -259,6 +259,45 @@ int main(int argc, char *argv[])
exit(0);
}
+void detect_and_repair_time_skew(const char *last_date, char *date, int n,
+ PatchSetMember *psm)
+{
+
+ time_t smaller;
+ time_t bigger;
+ struct tm *ts;
+ char *rev_end;
+
+ /* if last_date does not exist do nothing */
+ if (last_date[0] == '\0')
+ return;
+
+ /* TODO: repairing of branch times, skipping them for the moment */
+ /* check whether rev is of the form /1.[0-9]+/ */
+ if (psm->post_rev->rev[0] != '1' || psm->post_rev->rev[1] != '.')
+ return;
+ strtol(psm->post_rev->rev+2, &rev_end, 10);
+ if (*rev_end != '\0')
+ return;
+
+ /* important: because rlog is showing revisions backwards last_date should
+ * always be bigger than date */
+ convert_date(&bigger, last_date);
+ convert_date(&smaller, date);
+
+ if (difftime(bigger, smaller) <= 0) {
+ debug(DEBUG_APPMSG1, "broken revision date: %s -> %s file: %s, repairing.\n",
+ date, last_date, psm->file->filename);
+ if (!(bigger > 0)) {
+ debug(DEBUG_APPERROR, "timestamp underflow, exiting ... ");
+ exit(1);
+ }
+ smaller = bigger - 1;
+ ts = gmtime(&smaller);
+ strftime(date, n, "%Y-%m-%d %H:%M:%S", ts);
+ }
+}
+
static void load_from_cvs()
{
FILE * cvsfp;
@@ -267,6 +306,7 @@ static void load_from_cvs()
CvsFile * file = NULL;
PatchSetMember * psm = NULL;
char datebuff[20];
+ char last_datebuff[20];
char authbuff[AUTH_STR_MAX];
int logbufflen = LOG_STR_MAX + 1;
char * logbuff = malloc(logbufflen);
@@ -334,6 +374,8 @@ static void load_from_cvs()
exit(1);
}
+ /* initialize the last_datebuff with value indicating invalid date */
+ last_datebuff[0]='\0';
for (;;)
{
char * tst;
@@ -474,8 +516,14 @@ static void load_from_cvs()
{
if (psm)
{
+ detect_and_repair_time_skew(last_datebuff, datebuff, 20, psm);
PatchSet * ps = get_patch_set(datebuff, logbuff, authbuff, psm->post_rev->branch, psm);
patch_set_add_member(ps, psm);
+
+ /* remember last revision */
+ strncpy(last_datebuff, datebuff, 20);
+ /* just to be sure */
+ last_datebuff[19] = '\0';
}
logbuff[0] = 0;
@@ -487,8 +535,13 @@ static void load_from_cvs()
{
if (psm)
{
+ detect_and_repair_time_skew(last_datebuff, datebuff, 20, psm);
PatchSet * ps = get_patch_set(datebuff, logbuff, authbuff, psm->post_rev->branch, psm);
patch_set_add_member(ps, psm);
+
+ /* just finished the last revision of this file, set last_datebuff to invalid */
+ last_datebuff[0]='\0';
+
assign_pre_revision(psm, NULL);
}
--
1.6.1.2.390.gba743
^ permalink raw reply related
* [PATCH v3 2/2] cvsimport: extend testcase about patchset order to contain branches
From: Heiko Voigt @ 2009-03-18 17:33 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, ydirson, git
In-Reply-To: <49B52F74.1090006@alum.mit.edu>
This makes sure that timestamps and ordering on branches is not influenced
by a fix for cvsps.
The test extension does not deal which patchset correction on branches it
only verifes that branches are basically handled as before.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
t/t9603-cvsimport-patchsets.sh | 19 +++++++++----
t/t9603/cvsroot/.gitattributes | 1 +
t/t9603/cvsroot/module/a,v | 38 ++++++++++++++++++++++++-
t/t9603/cvsroot/module/b,v | 58 +++++++++++++++++++++++++++++++++++++---
4 files changed, 104 insertions(+), 12 deletions(-)
create mode 100644 t/t9603/cvsroot/.gitattributes
diff --git a/t/t9603-cvsimport-patchsets.sh b/t/t9603-cvsimport-patchsets.sh
index 15a971f..2511b69 100755
--- a/t/t9603-cvsimport-patchsets.sh
+++ b/t/t9603-cvsimport-patchsets.sh
@@ -17,17 +17,24 @@ test_description='git cvsimport testing for correct patchset estimation'
CVSROOT="$TEST_DIRECTORY"/t9603/cvsroot
export CVSROOT
-test_expect_failure 'import with criss cross times on revisions' '
+test_expect_success 'import with criss cross times on revisions' '
git cvsimport -p"-x" -C module-git module &&
cd module-git &&
- git log --pretty=format:%s > ../actual &&
- echo "" >> ../actual &&
+ git log --pretty=format:%s > ../actual-master &&
+ git log A~2..A --pretty="format:%s %ad" -- > ../actual-A &&
+ echo "" >> ../actual-master &&
+ echo "" >> ../actual-A &&
cd .. &&
- echo "Rev 3
+ echo "Rev 4
+Rev 3
Rev 2
-Rev 1" > expect &&
- test_cmp actual expect
+Rev 1" > expect-master &&
+ test_cmp actual-master expect-master &&
+
+ echo "Rev 5 Branch A Wed Mar 11 19:09:10 2009 +0000
+Rev 4 Branch A Wed Mar 11 19:03:52 2009 +0000" > expect-A &&
+ test_cmp actual-A expect-A
'
test_done
diff --git a/t/t9603/cvsroot/.gitattributes b/t/t9603/cvsroot/.gitattributes
new file mode 100644
index 0000000..562b12e
--- /dev/null
+++ b/t/t9603/cvsroot/.gitattributes
@@ -0,0 +1 @@
+* -whitespace
diff --git a/t/t9603/cvsroot/module/a,v b/t/t9603/cvsroot/module/a,v
index e86adfc..ba8fd5a 100644
--- a/t/t9603/cvsroot/module/a,v
+++ b/t/t9603/cvsroot/module/a,v
@@ -1,13 +1,15 @@
head 1.2;
access;
-symbols;
+symbols
+ A:1.2.0.2;
locks; strict;
comment @# @;
1.2
date 2009.02.21.18.11.14; author tester; state Exp;
-branches;
+branches
+ 1.2.2.1;
next 1.1;
1.1
@@ -15,6 +17,16 @@ date 2009.02.21.18.11.43; author tester; state Exp;
branches;
next ;
+1.2.2.1
+date 2009.03.11.19.03.52; author tester; state Exp;
+branches;
+next 1.2.2.2;
+
+1.2.2.2
+date 2009.03.11.19.09.10; author tester; state Exp;
+branches;
+next ;
+
desc
@@
@@ -29,6 +41,28 @@ text
@
+1.2.2.1
+log
+@Rev 4 Branch A
+@
+text
+@d1 1
+a1 1
+1.2.2.1
+@
+
+
+1.2.2.2
+log
+@Rev 5 Branch A
+@
+text
+@d1 1
+a1 1
+1.2.2.2
+@
+
+
1.1
log
@Rev 1
diff --git a/t/t9603/cvsroot/module/b,v b/t/t9603/cvsroot/module/b,v
index ab3089f..d268855 100644
--- a/t/t9603/cvsroot/module/b,v
+++ b/t/t9603/cvsroot/module/b,v
@@ -1,13 +1,20 @@
-head 1.2;
+head 1.3;
access;
-symbols;
+symbols
+ A:1.2.0.2;
locks; strict;
comment @# @;
+1.3
+date 2009.03.11.19.05.08; author tester; state Exp;
+branches;
+next 1.2;
+
1.2
date 2009.02.21.18.11.43; author tester; state Exp;
-branches;
+branches
+ 1.2.2.1;
next 1.1;
1.1
@@ -15,17 +22,60 @@ date 2009.02.21.18.11.14; author tester; state Exp;
branches;
next ;
+1.2.2.1
+date 2009.03.11.19.03.52; author tester; state Exp;
+branches;
+next 1.2.2.2;
+
+1.2.2.2
+date 2009.03.11.19.09.10; author tester; state Exp;
+branches;
+next ;
+
desc
@@
+1.3
+log
+@Rev 4
+@
+text
+@1.3
+@
+
+
1.2
log
@Rev 3
@
text
-@1.2
+@d1 1
+a1 1
+1.2
+@
+
+
+1.2.2.1
+log
+@Rev 4 Branch A
+@
+text
+@d1 1
+a1 1
+1.2.2.1
+@
+
+
+1.2.2.2
+log
+@Rev 5 Branch A
+@
+text
+@d1 1
+a1 1
+1.2
@
--
1.6.1.2.390.gba743
^ permalink raw reply related
* [PATCH v3 1/2] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-03-18 17:33 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, ydirson, git
In-Reply-To: <49B52F74.1090006@alum.mit.edu>
Some cvs repositories may have time deviations in their recorded commits.
This is a test for one of such cases. These kind of repositories can happen
if the system time of cvs clients is not fully synchronised.
Consider the following sequence of events:
* client A commits file a r1.1
* client A commits file a r1.2, b r1.1
* client B commits file b r1.2 using the same timestamp as a r1.1
This can be resolved but due to cvsps ordering its patchsets solely based
on the timestamp. It only takes revision odering into account if there
is no difference in the timestamp.
I hit this bug when importing from a real repository which was originally
converted from another rcs based scm. Other import tools can handle this
correctly, e.g. parsecvs.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
t/t9603-cvsimport-patchsets.sh | 33 +++++++++++++++++++++++++++++
t/t9603/cvsroot/CVSROOT/.gitignore | 2 +
t/t9603/cvsroot/module/a,v | 40 ++++++++++++++++++++++++++++++++++++
t/t9603/cvsroot/module/b,v | 40 ++++++++++++++++++++++++++++++++++++
4 files changed, 115 insertions(+), 0 deletions(-)
create mode 100755 t/t9603-cvsimport-patchsets.sh
create mode 100644 t/t9603/cvsroot/CVSROOT/.gitignore
create mode 100644 t/t9603/cvsroot/module/a,v
create mode 100644 t/t9603/cvsroot/module/b,v
diff --git a/t/t9603-cvsimport-patchsets.sh b/t/t9603-cvsimport-patchsets.sh
new file mode 100755
index 0000000..15a971f
--- /dev/null
+++ b/t/t9603-cvsimport-patchsets.sh
@@ -0,0 +1,33 @@
+#!/bin/sh
+
+# Structure of the test cvs repository
+#
+# Message File:Content Commit Time
+# Rev 1 a: 1.1 2009-02-21 19:11:43 +0100
+# Rev 2 a: 1.2 b: 1.1 2009-02-21 19:11:14 +0100
+# Rev 3 b: 1.2 2009-02-21 19:11:43 +0100
+#
+# As you can see the commit of Rev 3 has the same time as
+# Rev 1 this leads to a broken import because of a cvsps
+# bug.
+
+test_description='git cvsimport testing for correct patchset estimation'
+. ./lib-cvs.sh
+
+CVSROOT="$TEST_DIRECTORY"/t9603/cvsroot
+export CVSROOT
+
+test_expect_failure 'import with criss cross times on revisions' '
+
+ git cvsimport -p"-x" -C module-git module &&
+ cd module-git &&
+ git log --pretty=format:%s > ../actual &&
+ echo "" >> ../actual &&
+ cd .. &&
+ echo "Rev 3
+Rev 2
+Rev 1" > expect &&
+ test_cmp actual expect
+'
+
+test_done
diff --git a/t/t9603/cvsroot/CVSROOT/.gitignore b/t/t9603/cvsroot/CVSROOT/.gitignore
new file mode 100644
index 0000000..3bb9b34
--- /dev/null
+++ b/t/t9603/cvsroot/CVSROOT/.gitignore
@@ -0,0 +1,2 @@
+history
+val-tags
diff --git a/t/t9603/cvsroot/module/a,v b/t/t9603/cvsroot/module/a,v
new file mode 100644
index 0000000..e86adfc
--- /dev/null
+++ b/t/t9603/cvsroot/module/a,v
@@ -0,0 +1,40 @@
+head 1.2;
+access;
+symbols;
+locks; strict;
+comment @# @;
+
+
+1.2
+date 2009.02.21.18.11.14; author tester; state Exp;
+branches;
+next 1.1;
+
+1.1
+date 2009.02.21.18.11.43; author tester; state Exp;
+branches;
+next ;
+
+
+desc
+@@
+
+
+1.2
+log
+@Rev 2
+@
+text
+@1.2
+@
+
+
+1.1
+log
+@Rev 1
+@
+text
+@d1 1
+a1 1
+1.1
+@
diff --git a/t/t9603/cvsroot/module/b,v b/t/t9603/cvsroot/module/b,v
new file mode 100644
index 0000000..ab3089f
--- /dev/null
+++ b/t/t9603/cvsroot/module/b,v
@@ -0,0 +1,40 @@
+head 1.2;
+access;
+symbols;
+locks; strict;
+comment @# @;
+
+
+1.2
+date 2009.02.21.18.11.43; author tester; state Exp;
+branches;
+next 1.1;
+
+1.1
+date 2009.02.21.18.11.14; author tester; state Exp;
+branches;
+next ;
+
+
+desc
+@@
+
+
+1.2
+log
+@Rev 3
+@
+text
+@1.2
+@
+
+
+1.1
+log
+@Rev 2
+@
+text
+@d1 1
+a1 1
+1.1
+@
--
1.6.1.2.390.gba743
^ permalink raw reply related
* [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-03-18 17:33 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, ydirson, git
In-Reply-To: <49B52F74.1090006@alum.mit.edu>
This is an updated version of the first patch and an addition to ensure
correct handling of branches in fixes.
The commit message of the first patch did not describe the problem
correctly.
The second patch adds branches to the testcase so a possible bugfix in
cvsps can be made sure that it retains a correct ordering on branches. I
would like to keep the commits seperate for a better illustration of the
purpose of this test.
There also a new bugfix for cvsps following this patch series.
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Eric Raible @ 2009-03-18 17:29 UTC (permalink / raw)
To: Santi Béjar; +Cc: Eric Raible, git
In-Reply-To: <adf1fd3d0903181004k2554ae90uc101aad64947be7@mail.gmail.com>
On Wed, Mar 18, 2009 at 10:04 AM, Santi Béjar <santi@agolina.net> wrote:
> Gitk paints lines of development (lineal history without merges nor
> forks) with the same color.
>
> HTH,
> Santi
Thanks for the quick reply. I suppose I realized that but it just
doesn't seem that profound.
Don't get me wrong - I like gitk and still prefer it to any of the alternatives.
But its of color seems more flashy than useful to me.
Perhaps I'd be happier if the color of the nth parent of a merge
(selectable, first by default)
emerged from the merge? I dunno.
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Santi Béjar @ 2009-03-18 17:04 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20090318T164728-444@post.gmane.org>
2009/3/18 Eric Raible <raible+git@gmail.com>:
> This may be clueless (I suspect that it is) but I have never understood
> the meaning of the different line colors in gitk. They seems arbitrary to me.
>
> I get that the current HEAD is represented as a yellow dot, but that's it.
> (As an aside, it might be nice if merges had a different color dot than
> normal commits).
>
> Can anyone clue me in?
Gitk paints lines of development (lineal history without merges nor
forks) with the same color.
HTH,
Santi
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Eric Raible @ 2009-03-18 16:52 UTC (permalink / raw)
To: git
In-Reply-To: <20090318100512.GA7932@linux.vnet>
Allan Caffee <allan.caffee <at> gmail.com> writes:
>
> I know that _some_ people arn't particularly fond of colors, but I was
> wondering how difficult it would be to colorize the edges on the
> --graph drawn by the log command? It can be a little tricky trying to
> follow them with a relatively complex history. I was thinking something
> like gitk already does. Is anybody else interested in seeing this?
>
> ~Allan
This may be clueless (I suspect that it is) but I have never understood
the meaning of the different line colors in gitk. They seems arbitrary to me.
I get that the current HEAD is represented as a yellow dot, but that's it.
(As an aside, it might be nice if merges had a different color dot than
normal commits).
Can anyone clue me in?
- Eric
^ permalink raw reply
* RE: fetch and pull
From: John Dlugosz @ 2009-03-18 16:50 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Nanako Shiraishi, git, Junio C Hamano
In-Reply-To: <20090318153120.GC8118@atjola.homenet>
> Hm? Both clone and "remote add" setup the fetch line by default. So you
> manually adjusted the config to add the remote as just an url alias?
> I'm
> not convinced that such manual config changes are "normal" either. At
> least you're most likely the first user from which I've heard that he
> did that.
No, he manually added
[remote "pub"]
url = //...
only.
I'm sure he wouldn't know "clone" if it bit him. I assume the entire repository and working tree was simply copied from his machine.
This is the same guy who insists on rebasing the dev branch. As soon as I learned to use "git log" I tried to convince him that he should merge, not rebase, but he won't listen. So I got control and did the merge (not rebase) and am trying to device a work-flow and matching cook book for the team.
Nobody thought to post to this mailing list either. So you have a selection bias in your sample. I speculate that there is a larger population of people who use git poorly, and that includes not participating in the community to learn better.
Just like you can write Fortran in any language, git happily lets you treat it like SourceSafe, with a dash of "just enough knowledge to be dangerous" use of other features.
--John
(sorry about the footer)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Teemu Likonen @ 2009-03-18 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0903181657180.10279@pacific.mpi-cbg.de>
On 2009-03-18 17:01 (+0100), Johannes Schindelin wrote:
>> The default was not to change the window or depth at all. As
>> suggested by Jon Smirl, Linus Torvalds and others, default to
>>
>> --window=250 --depth=250
> Guess what. This is still unresolved, and yet somebody else had to be
> bitten by 'git gc --aggressive' being everything but aggressive.
Pieter de Bie's tests seem to suggest that usually --window=50
--depth=50 gives about the same results than with higher values:
http://vcscompare.blogspot.com/2008/06/git-repack-parameters.html
I don't understand the issue very well myself so I really can't say what
would be a/the good value. Anyway, I agree that it would be nice if "git
gc --aggressive" were aggressive and a user wouldn't need to know about
"git repack" and its cryptical low-levelish options.
^ permalink raw reply
* Re: GitTogether '09
From: Shawn O. Pearce @ 2009-03-18 16:11 UTC (permalink / raw)
To: Scott Chacon; +Cc: Sverre Rabbelier, Christian Couder, git, gittogether
In-Reply-To: <d411cc4a0903180905x1cb2a1c2j87922300dbf77e7b@mail.gmail.com>
Scott Chacon <schacon@gmail.com> wrote:
> On Wed, Mar 18, 2009 at 7:35 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > There is also the most popular issue of budgets. ??GitTogether '08
> > wasn't free for us. ??Its cheaper than anything we would get from a
> > conference venue/hotel outside the Googleplex, but it still was a
> > non-trivial sum. ??We simply may not have the funds for it this year.
>
> Let me know if I can help out at all. If Google doesn't want to host
> it, but everyone still wants to string together the GSOC summit and
> this, I'm sure GitHub can find a nice venue for us and get some food
> and whatnot. Or, if we can simply 'sponsor' it or something - give
> the Goog money to host it for us, however that might work. We want to
> help this happen again this year, so keep me in the loop and we can
> make sure it gets handled somehow.
Hey Scott, thanks. FWIW, Google doesn't co-sponsor events. So if we
do host it, we'll cover everything like we did last year, but maybe
GitHub can sponsor an off-site dinner again, like it did last year.
But perhaps this year you guys could select the venue for that. :-)
Anyway, today is not the best day to go asking for budget and time
from LH (big GSoC announcement today). Give me a week or two to
figure out if Google can host us here or in Portland. FWIW, last
year Portland around the Linux Plumbers conference was tossed out
as an option, but it was too close calendar wise to be possible
for planning purposes.
--
Shawn.
^ permalink raw reply
* Re: GitTogether '09
From: Scott Chacon @ 2009-03-18 16:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, Christian Couder, git, gittogether
In-Reply-To: <20090318143532.GD23521@spearce.org>
Hey,
On Wed, Mar 18, 2009 at 7:35 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> On Wed, Mar 18, 2009 at 08:05, Christian Couder <chriscool@tuxfamily.org> wrote:
>> > I thought that it was only one international airplane ticket last year,
>> > except perhaps when there are no US based mentor. And we are not sure that
>> > Google or another company in the Bay Area will be able to host us this
>> > year. So the cost of hosting the GitTogether might be higher than the cost
>> > of a few airplane tickets.
>>
>> Last year Google provided two international airplane tickets and was
>> able to host us, we can at least ask them to host us again this year
>> (if that is what we decide on).
>
> Did Google do two international tickets last year for Git? Hmm,
> don't go spreading that word around. Very few groups got that
> amount of travel money for the mentor summit. Maybe none others.
>
> IMHO, _if_ Git is accepted this year, and _if_ the mentor summit is
> held this fall as it has been in the past, Google will most likely
> cover only one ticket, especially if we actually also supported a
> GitTogether immediately after.
>
>> Shawn, how likely is it that Google will provide hosting for another
>> GitTogether this year?
>
> I will ask.
>
> Last year it was difficult on LH. Despite the fact that most of
> the attendees probably never even met her, she put a lot of work
> into the GitTogether behind the scenes. Without her efforts,
> the GitTogether simply would not have happened here.
>
> It was also *immediately* after the biggest event of the year
> that she and her team run (GSoC mentor summit), and really close
> to two other very big events that they run. They were working
> pretty much 7 days a week for over 3 months straight, and were
> really looking forward to some time off when I threw GitTogether
> '08 into their calendar.
>
> I'm not sure I can ask LH to put her and her team through that again.
> I want to continue living. :-)
>
> There is also the most popular issue of budgets. GitTogether '08
> wasn't free for us. Its cheaper than anything we would get from a
> conference venue/hotel outside the Googleplex, but it still was a
> non-trivial sum. We simply may not have the funds for it this year.
Let me know if I can help out at all. If Google doesn't want to host
it, but everyone still wants to string together the GSOC summit and
this, I'm sure GitHub can find a nice venue for us and get some food
and whatnot. Or, if we can simply 'sponsor' it or something - give
the Goog money to host it for us, however that might work. We want to
help this happen again this year, so keep me in the loop and we can
make sure it gets handled somehow.
Scott
>
> --
> Shawn.
> --
> 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
>
^ permalink raw reply
* Re: [EGIT RFC PATCH(was Re: egit problem with sym linked eclipse project dirs)] Add some support for symlinked projects.
From: Stephen Bannasch @ 2009-03-18 16:02 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200903120756.07853.robin.rosenberg.lists@dewire.com>
At 7:56 AM +0100 3/12/09, Robin Rosenberg wrote:
>torsdag 12 mars 2009 03:57:09 skrev Stephen Bannasch
><stephen.bannasch@deanbrook.org>:
>> OK ... I'm a bit confused now because I no longer have Git listed as
>> a repository type for Team Sharing.
>>
> > I deleted the existing org.spearce.* eclipse plugins
...
> > The new plugins are there:
>>
>> [eclipse]$ ls plugins/org.spearce.*
>> plugins/org.spearce.egit.core.test_0.4.0.200903112237.jar
>> plugins/org.spearce.egit_0.4.0.200903112237.jar
>> plugins/org.spearce.egit.core_0.4.0.200903112237.jar
>> plugins/org.spearce.jgit_0.4.0.200903112237.jar
>> plugins/org.spearce.egit.ui_0.4.0.200903112237.jar
>>
>> Quit and restarted Eclipse.
>>
>> When I select a project with an existing git repository and try to
>> enable team/sharing only CVS and SVN are listed.
>
>You don't have the a matching feature. That could be it, but I'm not sure.
>You can also try starting eclipse witth the -clean switch. Looking at the
><workspace>/.metadata/.log could also give you some hints.
I figured out the problem I had when testing the patched egit plugin.
If I had installed egit from the update site I had to do more than
just delete the jars -- I had to delete the whole feature from within
Eclipse -- and then install the new plugin built from source.
In figuring this out I ended up testing the original problem with the
master branch from earlier today and didn't see the issue I
originally reported.
Did you already integrate the experimental patch?
Here's a documentation patch:
From feb1ae0ccf7f671506853f4f49e9041950404b3d Mon Sep 17 00:00:00 2001
From: Stephen Bannasch <stephen.bannasch@gmail.com>
Date: Wed, 18 Mar 2009 11:51:56 -0400
Subject: [PATCH] clarify how to delete egit plugin when installing new build
---
EGIT_INSTALL | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/EGIT_INSTALL b/EGIT_INSTALL
index 3a8f249..3a9c209 100644
--- a/EGIT_INSTALL
+++ b/EGIT_INSTALL
@@ -21,7 +21,16 @@ things.
INSTALLATION INSTRUCTIONS
-- Delete any old versions of the plugin in the
<eclipse-path>/plugins/org.spearce.*
+First remove any existing egit plugin.
+
+If you have installed egit from the egit update site
http://www.jgit.org/update-site:
+
+ delete the plugin from Software Updates and Add-ons from within Eclipse
+
+If you have installed the plugin from source:
+
+ delete any old versions of the plugin jars in the
<eclipse-path>/plugins/org.spearce.*
+
- Start eclipse
- Make sure a recent JDK 1.5.0_11 or JDK 1.6.x is among your
installed JRE's. Which
one is the default should not matter but Java 6 is recommended.
--
1.6.1.2
>For debugging/testing in general it is often easier to launch Eclipse from
>eclipse (Run As) without reinstalling.
As part of this test I need to switch to another workspace and I
couldn't get that working with "Run As".
^ permalink raw reply related
* Re: [PATCH] gc --aggressive: make it really aggressive
From: Johannes Schindelin @ 2009-03-18 16:01 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <Pine.LNX.4.64.0712061201580.27959@racer.site>
Hi,
On Thu, 6 Dec 2007, Johannes Schindelin wrote:
>
> The default was not to change the window or depth at all. As suggested
> by Jon Smirl, Linus Torvalds and others, default to
>
> --window=250 --depth=250
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Guess what. This is still unresolved, and yet somebody else had to be
bitten by 'git gc --aggressive' being everything but aggressive.
So... I think it is high time to resolve the issue, either by applying
this patch with a delay of over one year, or by the pack wizards trying to
implement that 'never fall back to a worse delta' idea mentioned in this
thread.
Although I suggest, really, that implying --depth=250 --window=250 (unless
overridden by the config) with --aggressive is not at all wrong.
Ciao,
Dscho
^ 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