* GIT maintenance on ia64 test tree
From: Luck, Tony @ 2005-11-11 0:59 UTC (permalink / raw)
To: linux-ia64, git; +Cc: Andrew Morton
The way that I'm using GIT to maintain my test/release
trees results in the test tree building a history of
extra fluff (lots of auto-updates from Linus, plus all
the merge-commits to bring in each of the patch-sets, plus
some mistakes from when I goofed with GIT).
So, I'm going to periodically blow away the test branch
and re-create a clean version. This mail is advance
notice that I'm going to do this when Linus releases
2.6.15-rc1 (a convenient point since I just sent everything
that was cooking in test to Linus ... so the test tree is
currently empty).
What this means is that the new "test" branch won't have
any connection to the old "test" branch. So a "git pull"
or "git fetch" will fail. To fix this in native git I *think*
you need to run (git list copied in the hope that if this is
tragically wrong, or overly complex, someone will take pity
and explain how it should be done):
$ git checkout
{any-branch-other-than-the-one-you-track-my-test-tree-with}
$ git branch -D test
$ git branch test v2.6.15-rc1
Note that this will orphan all the objects relating to the
history of the test branch. You can clean up with:
$ git prune
BUT, this will also throw away any other orphaned stuff too, so
only do this if you are ok with ditching this. You could run
$ git fsck-objects
before any of the above to see whether you have any orphans.
Cogito users ... I have no idea. First one to figure it out
please post a recipe.
-Tony
^ permalink raw reply
* Re: [PATCH] Make git-pack-redundant consider alt-odbs
From: Junio C Hamano @ 2005-11-11 0:40 UTC (permalink / raw)
To: git; +Cc: Lukas =?iso-2022-jp-2?B?U2FuZHN0chsuQRtOdm0=?=
In-Reply-To: <4373E4E0.10903@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 317 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> [PATCH] Make git-pack-redundant consider alt-odbs
>
> This patch changes git-pack-redundant so that packfiles
> ...
This request is not just for Lukas, but people, please do not
duplicate what is already on the Subject: line at the top of
your message body.
^ permalink raw reply
* [PATCH] Make git-pack-redundant consider alt-odbs
From: Lukas Sandström @ 2005-11-11 0:25 UTC (permalink / raw)
To: git; +Cc: junkio, Lukas Sandström
[PATCH] Make git-pack-redundant consider alt-odbs
This patch changes git-pack-redundant so that packfiles
in alternate object directories also are considered when
deciding which objects are redundant.
This functionality is controlled by the flag '--alt-odb'.
Also convert the other flags to the long form, and update
docs and git-repack accordingly.
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
---
On a related note; if you have unreachable objects in your
packfiles, those objects might make otherwise redundant
packfiles non-redundant.
Would it be a useful feature to be able to give git-pack-redundant
a list of bad objects on stdin, which then will be ignored?
(eg. git-fsck-objects --full --unreachable | cut -s -d ' ' -f 3 | git-pack-redundant)
Documentation/git-pack-redundant.txt | 19 +++-
git-repack.sh | 4 -
pack-redundant.c | 147 ++++++++++++++++++++++------------
3 files changed, 107 insertions(+), 63 deletions(-)
applies-to: 8f520c14677a07c01eb64f64bcd68cb174392ec9
ad7d016fcecacdfaf9cf0cc4b65fadf32e86899b
diff --git a/Documentation/git-pack-redundant.txt b/Documentation/git-pack-redundant.txt
index 3829616..2e23cbc 100644
--- a/Documentation/git-pack-redundant.txt
+++ b/Documentation/git-pack-redundant.txt
@@ -8,7 +8,7 @@ git-pack-redundant - Program used to fin
SYNOPSIS
--------
-'git-pack-redundant [ -v ] < -a | .pack filename ... >'
+'git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >'
DESCRIPTION
-----------
@@ -19,13 +19,16 @@ are redundant. The output is suitable fo
OPTIONS
-------
--v::
- Verbose. Outputs some statistics to stderr.
- Has a small performance penalty.
-
--a::
- All. Processes all the local packs. Any filenames on
- the commandline are ignored.
+
+--all::
+ Processes all packs. Any filenames on the commandline are ignored.
+
+--alt-odb::
+ Don't require objects present in packs from alternate object
+ directories to be present in local packs.
+
+--verbose::
+ Outputs some statistics to stderr. Has a small performance penalty.
Author
------
diff --git a/git-repack.sh b/git-repack.sh
index 4ce0022..f347207 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -45,7 +45,7 @@ if [ -z "$name" ]; then
if test "$remove_redandant" = t ; then
echo "Removing redundant packs."
sync
- redundant=$(git-pack-redundant -a)
+ redundant=$(git-pack-redundant --all)
if test "$redundant" != "" ; then
echo $redundant | xargs rm
fi
@@ -63,7 +63,7 @@ exit
if test "$remove_redandant" = t
then
sync
- redundant=$(git-pack-redundant -a)
+ redundant=$(git-pack-redundant --all)
if test "$redundant" != "" ; then
echo $redundant | xargs rm
fi
diff --git a/pack-redundant.c b/pack-redundant.c
index db3dcde..1f8c577 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -9,9 +9,9 @@
#include "cache.h"
static const char pack_redundant_usage[] =
-"git-pack-redundant [ -v ] < -a | <.pack filename> ...>";
+"git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | <.pack filename> ...>";
-int all = 0, verbose = 0;
+int load_all_packs = 0, verbose = 0, alt_odb = 0;
struct llist_item {
struct llist_item *next;
@@ -21,14 +21,14 @@ struct llist {
struct llist_item *front;
struct llist_item *back;
size_t size;
-} *all_objects;
+} *all_objects; /* all objects which must be present in local packfiles */
struct pack_list {
struct pack_list *next;
struct packed_git *pack;
struct llist *unique_objects;
struct llist *all_objects;
-} *pack_list;
+} *local_packs = NULL, *altodb_packs = NULL;
struct pll {
struct pll *next;
@@ -128,32 +128,35 @@ inline struct llist_item * llist_insert_
}
/* computes A\B */
-struct llist * llist_sorted_difference(struct llist_item *A,
- struct llist_item *B)
+void llist_sorted_difference_inplace(struct llist *A,
+ struct llist *B)
{
- struct llist *ret;
- llist_init(&ret);
+ struct llist_item *prev, *a, *b, *x;
- while (A != NULL && B != NULL) {
- int cmp = memcmp(A->sha1, B->sha1, 20);
+ prev = a = A->front;
+ b = B->front;
+
+ while (a != NULL && b != NULL) {
+ int cmp = memcmp(a->sha1, b->sha1, 20);
if (!cmp) {
- A = A->next;
- B = B->next;
- continue;
- }
- if(cmp > 0) { /* we'll never find this B */
- B = B->next;
- continue;
- }
- /* A has the object, B doesn't */
- llist_insert_back(ret, A->sha1);
- A = A->next;
- }
- while (A != NULL) {
- llist_insert_back(ret, A->sha1);
- A = A->next;
+ x = a;
+ if (a == A->front)
+ A->front = a->next;
+ a = prev->next = a->next;
+
+ if (a == NULL) /* end of list */
+ A->back = prev;
+ A->size--;
+ free(x);
+ b = b->next;
+ } else
+ if (cmp > 0)
+ b = b->next;
+ else {
+ prev = a;
+ a = a->next;
+ }
}
- return ret;
}
/* returns a pointer to an item in front of sha1 */
@@ -201,6 +204,16 @@ inline struct pack_list * pack_list_inse
return p;
}
+inline size_t pack_list_size(struct pack_list *pl)
+{
+ size_t ret = 0;
+ while(pl) {
+ ret++;
+ pl = pl->next;
+ }
+ return ret;
+}
+
struct pack_list * pack_list_difference(struct pack_list *A,
struct pack_list *B)
{
@@ -294,15 +307,13 @@ struct pll * get_all_permutations(struct
int is_superset(struct pack_list *pl, struct llist *list)
{
- struct llist *diff, *old;
+ struct llist *diff;
diff = llist_copy(list);
while (pl) {
- old = diff;
- diff = llist_sorted_difference(diff->front,
- pl->all_objects->front);
- llist_free(old);
+ llist_sorted_difference_inplace(diff,
+ pl->all_objects);
if (diff->size == 0) { /* we're done */
llist_free(diff);
return 1;
@@ -347,6 +358,10 @@ size_t sizeof_union(struct packed_git *p
size_t get_pack_redundancy(struct pack_list *pl)
{
struct pack_list *subset;
+
+ if (pl == NULL)
+ return 0;
+
size_t ret = 0;
while ((subset = pl->next)) {
while(subset) {
@@ -374,10 +389,10 @@ void minimize(struct pack_list **min)
struct pack_list *pl, *unique = NULL,
*non_unique = NULL, *min_perm = NULL;
struct pll *perm, *perm_all, *perm_ok = NULL, *new_perm;
- struct llist *missing, *old;
+ struct llist *missing;
size_t min_perm_size = (size_t)-1, perm_size;
- pl = pack_list;
+ pl = local_packs;
while (pl) {
if(pl->unique_objects->size)
pack_list_insert(&unique, pl);
@@ -389,13 +404,12 @@ void minimize(struct pack_list **min)
missing = llist_copy(all_objects);
pl = unique;
while (pl) {
- old = missing;
- missing = llist_sorted_difference(missing->front,
- pl->all_objects->front);
- llist_free(old);
+ llist_sorted_difference_inplace(missing,
+ pl->all_objects);
pl = pl->next;
}
+ /* return if there are no objects missing from the unique set */
if (missing->size == 0) {
*min = unique;
return;
@@ -437,7 +451,7 @@ void minimize(struct pack_list **min)
void load_all_objects()
{
- struct pack_list *pl = pack_list;
+ struct pack_list *pl = local_packs;
struct llist_item *hint, *l;
int i;
@@ -454,17 +468,34 @@ void load_all_objects()
}
pl = pl->next;
}
+ /* remove objects present in remote packs */
+ pl = altodb_packs;
+ while (pl) {
+ llist_sorted_difference_inplace(all_objects, pl->all_objects);
+ pl = pl->next;
+ }
}
/* this scales like O(n^2) */
void cmp_packs()
{
- struct pack_list *subset, *curr = pack_list;
+ struct pack_list *subset, *pl = local_packs;
- while ((subset = curr)) {
+ while ((subset = pl)) {
while((subset = subset->next))
- cmp_two_packs(curr, subset);
- curr = curr->next;
+ cmp_two_packs(pl, subset);
+ pl = pl->next;
+ }
+
+ pl = altodb_packs;
+ while (pl) {
+ subset = local_packs;
+ while (subset) {
+ llist_sorted_difference_inplace(subset->unique_objects,
+ pl->all_objects);
+ subset = subset->next;
+ }
+ pl = pl->next;
}
}
@@ -485,7 +516,10 @@ struct pack_list * add_pack(struct packe
}
/* this list will be pruned in cmp_two_packs later */
l.unique_objects = llist_copy(l.all_objects);
- return pack_list_insert(&pack_list, &l);
+ if (p->pack_local)
+ return pack_list_insert(&local_packs, &l);
+ else
+ return alt_odb ? pack_list_insert(&altodb_packs, &l) : NULL;
}
struct pack_list * add_pack_file(char *filename)
@@ -497,7 +531,6 @@ struct pack_list * add_pack_file(char *f
while (p) {
if (strstr(p->pack_name, filename))
- /* this will silently ignore packs in alt-odb */
return add_pack(p);
p = p->next;
}
@@ -509,8 +542,7 @@ void load_all()
struct packed_git *p = packed_git;
while (p) {
- if (p->pack_local) /* ignore alt-odb for now */
- add_pack(p);
+ add_pack(p);
p = p->next;
}
}
@@ -526,14 +558,18 @@ int main(int argc, char **argv)
i++;
break;
}
- if(!strcmp(arg, "-a")) {
- all = 1;
+ if(!strcmp(arg, "--all")) {
+ load_all_packs = 1;
continue;
}
- if(!strcmp(arg, "-v")) {
+ if(!strcmp(arg, "--verbose")) {
verbose = 1;
continue;
}
+ if(!strcmp(arg, "--alt-odb")) {
+ alt_odb = 1;
+ continue;
+ }
if(*arg == '-')
usage(pack_redundant_usage);
else
@@ -542,13 +578,13 @@ int main(int argc, char **argv)
prepare_packed_git();
- if(all)
+ if (load_all_packs)
load_all();
else
while (*(argv + i) != NULL)
add_pack_file(*(argv + i++));
- if (pack_list == NULL)
+ if (local_packs == NULL)
die("Zero packs found!\n");
cmp_packs();
@@ -557,6 +593,8 @@ int main(int argc, char **argv)
minimize(&min);
if (verbose) {
+ fprintf(stderr, "There are %ld packs available in alt-odbs.\n",
+ pack_list_size(altodb_packs));
fprintf(stderr, "The smallest (bytewise) set of packs is:\n");
pl = min;
while (pl) {
@@ -566,12 +604,15 @@ int main(int argc, char **argv)
fprintf(stderr, "containing %ld duplicate objects "
"with a total size of %ldkb.\n",
get_pack_redundancy(min), pack_set_bytecount(min)/1024);
+ fprintf(stderr, "A total of %ld unique objects were considered.\n",
+ all_objects->size);
fprintf(stderr, "Redundant packs (with indexes):\n");
}
- pl = red = pack_list_difference(pack_list, min);
+ pl = red = pack_list_difference(local_packs, min);
while (pl) {
printf("%s\n%s\n",
- sha1_pack_index_name(pl->pack->sha1), pl->pack->pack_name);
+ sha1_pack_index_name(pl->pack->sha1),
+ pl->pack->pack_name);
pl = pl->next;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Pavel Roskin @ 2005-11-11 0:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, git
In-Reply-To: <20051110234029.GE30496@pasky.or.cz>
On Fri, 2005-11-11 at 00:40 +0100, Petr Baudis wrote:
> Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter
> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > Why would anybody want to fetch the current upstream HEAD at cg-pull
> > time? If you do this, and you have no control on the upstream
> > repository, "origin" will jump randomly around after cg-pull, depending
> > on the current HEAD of the origin repository.
>
> In public repositories, you usually set the HEAD once and it stays
> there, or when you switch it, you are really careful about it.
Correct. But if it's a concern, I think we could make some
improvements. Following approaches could be tried (starting from top,
using following steps as a fallback):
1) Use recorded branch, i.e. the branch name that was used in cg-clone.
2) Check a file specifying the default branch for cloning (let's call it
e.g. .git/default_export). Record branch name.
3) If cg-switch is implemented, another file would be likely used to
specify the default branch for local operations
(e.g. .git/default_branch). Use it. Record branch name.
4) If .git/HEAD can be recognized as link (we may need to eliminate
symlinks for that to work over remote transport), use the branch it
points to. Record branch name.
5) If .git/HEAD cannot be recognized as link, use it as the branch to
clone. Don't record the branch name. (I'm not sure if we really want
that - it's good to know what branch we are using).
6) Use "master" branch. Record branch name.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: proper way to make cg-fetch work from originally git-clone'd tree
From: Randal L. Schwartz @ 2005-11-11 0:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111001148.GG30496@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
>> cg-merge 2>&1 | grep -v 'already fully merged' && make prefix=/opt/git all install && (cd Documentation && make prefix=/opt/git all install)
Petr> Any reason why you were unable to tell the main make 'doc install-doc'?
Because I didn't see it? :-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: cg-admin-setuprepo fails to make a cg-clone'able repo
From: Petr Baudis @ 2005-11-11 0:13 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Git Mailing List
In-Reply-To: <86wtjg31lo.fsf@blue.stonehenge.com>
Dear diary, on Thu, Nov 10, 2005 at 05:32:35PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> Repeat by:
>
> cg-admin-setuprepo repo
> cg-clone $(PWD)/repo myview
You should cg-init locally, then cg-admin-setuprepo the public one and
push to it. I updated cg-admin-setuprepo's description wrt. that now.
> Results:
>
> defaulting to local storage area
> Hard links don't work - using copy
> cp: illegal option -- b
> usage: cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src target
> cp [-R [-H | -L | -P]] [-f | -i | -n] [-pv] src1 ... srcN directory
> cg-fetch: unable to get the HEAD branch
> cg-clone: fetch failed
But this is actually an entirely unrelated bug, it seems - pretty
strange. I revived another few months old thread because of this, since
it seems the 'b' was actually a typo and we don't want to pass 'cp' this
argument at all, but something different. Does cloning locally otherwise
work?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: proper way to make cg-fetch work from originally git-clone'd tree
From: Petr Baudis @ 2005-11-11 0:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzkc4nlu.fsf@blue.stonehenge.com>
Dear diary, on Thu, Nov 10, 2005 at 02:51:57PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> I tried git-fetch this morning, and it said I didn't have an origin,
> which makes sense because I made the tree with git-clone, not cg-clone.
>
> However, when I tried
>
> cg-branch-add origin rsync://rsync.kernel.org/pub/scm/git/git.git
>
> it complained that I already had an origin! It seems to work after
> that, but what should I have done instead? Is there a way to make
> both cg-fetch and git-fetch to default to the same things?
You should do what you did - it was just a warning. git-clone seems to
have created only a 'remotes' entry, which Cogito doesn't understand
(yet).
> By the way, my "make only if something changed" works now, because
> I've separated cg-fetch and cg-merge. My merge step looks like:
>
> cg-merge 2>&1 | grep -v 'already fully merged' && make prefix=/opt/git all install && (cd Documentation && make prefix=/opt/git all install)
Any reason why you were unable to tell the main make 'doc install-doc'?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Petr Baudis @ 2005-11-11 0:09 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Pavel Roskin
In-Reply-To: <200511110056.54476.Josef.Weidendorfer@gmx.de>
Dear diary, on Fri, Nov 11, 2005 at 12:56:54AM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> Still I think my reasoning holds: cg-clone is also used locally, thus
> cloning a repository on which you probably are working on, too.
Yes, that's a valid point, but I still think for the usual case
defaulting to HEAD is the right thing to do. But it wasn't described
in the documentation and that's indeed a bug - fixed now.
> If I want to branch off from master, I can use cg-clone to start a new
> development branch. I suppose this is the suggested Cogito way, from
> the README; and it makes Cogitos usage so simple, even with multiple
> development branches: by using a cloned repository for each branch.
Yes, this is the recommended workflow. Well, if you plan to switch
branches randomly in your "central private repository", better explicitly
specify #master in the offsprings. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Josef Weidendorfer @ 2005-11-10 23:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Pavel Roskin
In-Reply-To: <20051110234029.GE30496@pasky.or.cz>
On Friday 11 November 2005 00:40, Petr Baudis wrote:
> Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter
> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:
> > > Hello!
> > >
> > > This patch changes cg-pull so that if the branch is not specified, it
> > > takes origin's .git/HEAD without first trying .git/refs/heads/master.
> > > This removes preferential treatment of the "master" branch, allowing the
> > > upstream to use another name for the default branch. To get the master
> > > branch, users would have to append "#master" to the URL.
> ...
> > Or am I missing something here?
>
> That this is from 23 August and this change was in Cogito for several
> major releases and noone ever complained. ;-)
You catched me ;-)
Still I think my reasoning holds: cg-clone is also used locally, thus
cloning a repository on which you probably are working on, too.
If I want to branch off from master, I can use cg-clone to start a new
development branch. I suppose this is the suggested Cogito way, from
the README; and it makes Cogitos usage so simple, even with multiple
development branches: by using a cloned repository for each branch.
Of course, a Git user would use "git branch ...", and switch between
branches inside of one repository.
Josef
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Petr Baudis @ 2005-11-10 23:40 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Pavel Roskin
In-Reply-To: <200511110026.18324.Josef.Weidendorfer@gmx.de>
Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:
> > Hello!
> >
> > This patch changes cg-pull so that if the branch is not specified, it
> > takes origin's .git/HEAD without first trying .git/refs/heads/master.
> > This removes preferential treatment of the "master" branch, allowing the
> > upstream to use another name for the default branch. To get the master
> > branch, users would have to append "#master" to the URL.
>
> I think this is wrong.
>
> Why would anybody want to fetch the current upstream HEAD at cg-pull
> time? If you do this, and you have no control on the upstream
> repository, "origin" will jump randomly around after cg-pull, depending
> on the current HEAD of the origin repository.
In public repositories, you usually set the HEAD once and it stays
there, or when you switch it, you are really careful about it.
> Besides, this is a incompatible change in cg-pull behavior: I am sure that
> a lot of people did a cg-clone in the past without any specific remote branch,
> and expect that cg-pull will update their origin to the remote "master".
> Now, if they update to a new Cogito with this patch, the next cg-pull
> sometimes will rebase their origin to another random branch, depending
> on remote HEAD ?!
See above. The remote HEAD is supposed to be generally stable for public
repositories, pointing to the _default_ head for public consumption.
If you want something specific, specify it by the #branchname.
> Or am I missing something here?
That this is from 23 August and this change was in Cogito for several
major releases and noone ever complained. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Petr Baudis @ 2005-11-10 23:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4373CEA8.1020900@op5.se>
Dear diary, on Thu, Nov 10, 2005 at 11:50:16PM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> Linus Torvalds wrote:
> >
> >And the performance difference does seem to be quite noticeable too..
> >
>
> Yes. I was quite astonished when I noticed first, thinking the shell
> kept the parsed script in cache or some such. Apparently it doesn't.
The bulk of the time is likely not spent parsing, but executing
subprocesses, that's hideously expensive. Just for fun, you can try to
measure the improvement when you remove the $(dirname "$0"). Here, for
1000 tries it's roughly 9s normal, 7s without dirname and 3s direct
invocation, which seems to give you _very roughly_ 2s per subprocess,
and 2s other shell overhead, which is unusually right.
Actually, I can bring the git.sh runtime from 7s to 4.7s:
- case "$cmd" in
- -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+ if [[ "$cmd" = "-v" ||
+ "$cmd" = "--v" ||
+ "$cmd" = "--ve" ||
+ "$cmd" = "--ver" ||
+ "$cmd" = "--vers" ||
+ "$cmd" = "--versi" ||
+ "$cmd" = "--versio" ||
+ "$cmd" = "--version" ]]; then
echo "git version @@GIT_VERSION@@"
exit 0 ;;
- esac
+ fi
(whitespace-mangled)
Well, subconsciously I never really trusted this case thing. ;-)
This leaves ~ 1.7s to other shell overhead and execve() (the main
command call is without the fork(), while $(dirname) fork()s).
> >>The location of the GIT_LIB can be obtained by running
> >>
> >> git --lib
> >
> >
> >I think this might be a bit ambiguous. When I see "GIT_LIB", to me it
> >implies traditional libraries (ie a "libgit.a" kind of thing), not the
> >kind of "git executable plugin" directory.
> >
> >So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a "--libexec"
> >kind of flavor, if only to avoid that confusion.
>
>
> Someone said libexec was moving out (of Linux, at least), so I thought
> I'd better avoid that. Perhaps GIT_LIBDIR?
This may not necessarily have anything in common with the actual
directory name. I prefer libexec too (but personally don't care too
much).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Josef Weidendorfer @ 2005-11-10 23:26 UTC (permalink / raw)
To: git; +Cc: Pavel Roskin, Petr Baudis
In-Reply-To: <1124832796.23795.9.camel@dv>
On Tuesday 23 August 2005 23:33, Pavel Roskin wrote:
> Hello!
>
> This patch changes cg-pull so that if the branch is not specified, it
> takes origin's .git/HEAD without first trying .git/refs/heads/master.
> This removes preferential treatment of the "master" branch, allowing the
> upstream to use another name for the default branch. To get the master
> branch, users would have to append "#master" to the URL.
I think this is wrong.
Why would anybody want to fetch the current upstream HEAD at cg-pull
time? If you do this, and you have no control on the upstream
repository, "origin" will jump randomly around after cg-pull, depending
on the current HEAD of the origin repository.
Besides, this is a incompatible change in cg-pull behavior: I am sure that
a lot of people did a cg-clone in the past without any specific remote branch,
and expect that cg-pull will update their origin to the remote "master".
Now, if they update to a new Cogito with this patch, the next cg-pull
sometimes will rebase their origin to another random branch, depending
on remote HEAD ?!
Or am I missing something here?
Josef
^ permalink raw reply
* Re: Expected Behavior?
From: Petr Baudis @ 2005-11-10 23:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vzmocw1xd.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 11:52:46PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> One thing I _don't_ like about both is there is no way for 'git
> reset --hard' to get rid of them, when the user decides to retry
> from scratch after seeing a failed merge that left too many of
> them.
Yes. You can cg-clean, but that'll wipe out other stuff as well. I plan
to fix that by adding some conflicts tracking to Cogito - I'm not yet
decided on the particular implementation (only that I certainly don't
want to require the user to manually tell Cogito about resolved
conflicts).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: rsync deprecated but promoted?
From: Petr Baudis @ 2005-11-10 23:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Coxall, Zack Brown, git
In-Reply-To: <Pine.LNX.4.58.0509260941340.3308@g5.osdl.org>
Dear diary, on Mon, Sep 26, 2005 at 06:43:08PM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> said that...
>
>
> On Mon, 26 Sep 2005, Petr Baudis wrote:
> >
> > Actually, it would be nice to be able to tell git-fsck-objects to only
> > verify objects which are referenced between given two commits (perhaps
> > just make it support the ^object notation). Then I wouldn't mind running
> > that after each rsync fetch in Cogito.
>
> You can kind of do it.
>
> Do
>
> git-rev-list --objects $oldheads --not $newheads >& /dev/null
> echo "$?"
>
> and it _should_ largely work. Untested, of course, but I _hope_ that if
> any object is missing, git-rev-list should die with an error. And if it
> doesn't, I should fix it ;)
It should obviously be
git-rev-list $(git-rev-parse $newheads --not $oldheads) >& /dev/null
but it is indeed broken:
$ git-rev-list --objects ... ^... && echo ':)'
001439c6a797461c3e75018d95744d463077ae33
841e3297d8df764da417da81dbfe1044e24d4082
cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f file
:)
$ git-cat-file -t cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f
error: unable to find cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f
fatal: git-cat-file cf11a3d561e76c8ba273cb0bb62d46a4b2959c1f: bad file
Currently I just modified it so that I iterate through all the sha1s
git-rev-list spits out, and test them by git-cat-file -t.
Thanks for the hint,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Expected Behavior?
From: Junio C Hamano @ 2005-11-10 22:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, git
In-Reply-To: <20051110203411.GX30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Wed, Nov 09, 2005 at 09:19:06AM CET, I got a letter
> where Fredrik Kuivinen <freku045@student.liu.se> said that...
>> On Tue, Nov 08, 2005 at 09:50:54PM -0800, Junio C Hamano wrote:
>> > Fredrik Kuivinen <freku045@student.liu.se> writes:
>> >
>> Oups, I haven't thought about that. I kind of like the idea that you
>> can see the branch name in the file names though. How about replacing
>> any slashes in the branch names with underscores? So the branch
>> 'foo/bar' will give rise to files with suffixes like '_foo_bar' and
>> '_foo_bar_<number>'.
>
> I like it too. :-)
>
> Now, this would look like file3~master in Cogito (or file3~~master in
> case of name conflict, etc.).
One thing I like about Cogito's is the use of tilde instead of
underscore -- much much less likely to clash with real filenames
and easiliy recognizable as throwaway copies.
One thing I _don't_ like about both is there is no way for 'git
reset --hard' to get rid of them, when the user decides to retry
from scratch after seeing a failed merge that left too many of
them.
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Andreas Ericsson @ 2005-11-10 22:50 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511101133550.4627@g5.osdl.org>
Linus Torvalds wrote:
>
> And the performance difference does seem to be quite noticeable too..
>
Yes. I was quite astonished when I noticed first, thinking the shell
kept the parsed script in cache or some such. Apparently it doesn't.
>
>>The location of the GIT_LIB can be obtained by running
>>
>> git --lib
>
>
> I think this might be a bit ambiguous. When I see "GIT_LIB", to me it
> implies traditional libraries (ie a "libgit.a" kind of thing), not the
> kind of "git executable plugin" directory.
>
> So I'd suggest renaming "--lib" and "GIT_LIB" to be more of a "--libexec"
> kind of flavor, if only to avoid that confusion.
Someone said libexec was moving out (of Linux, at least), so I thought
I'd better avoid that. Perhaps GIT_LIBDIR?
Btw, I re-visited ye ole "git binary directory?" thread and noticed the
nifty trick you did with PATH from the wrapper. I'll add that to git.c
and, unless I get a better suggestion, rename GIT_LIB to GIT_LIBDIR (and
git --libdir).
> Even if the actual
> directory ends up being /usr/lib/git-<version>/ as in my original
> suggestion, I think it's good to make it clear that it's not just some
> kind of "link type" library, but more of a combination of libraries and
> plugins and executables.
>
> But maybe that's just me?
>
It's not just you, but GIT_DIR was taken and I felt lazy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-archimport
From: Martin Langhoff @ 2005-11-10 22:21 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <20051110214959.GO9131@raven.localdomain>
On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784
Hmmm. The script uses tla itself to get the patch. What happens if you do
tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1
In short, you must have a recent tla configured and with the archive
registered.
cheers,
martin
^ permalink raw reply
* Re: git-archimport
From: Kevin Geiss @ 2005-11-10 21:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511101332r3389734uc1aa1effd2898e15@mail.gmail.com>
ok. I tried this:
git-archimport kevin@desertsol.com--files/scripts--base kevin@desertsol.com--files/scripts--oco
and it always complains:
Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784
I don't have any spaces or funny characters in filenames.
On Fri, Nov 11, 2005 at 10:32:12AM +1300, Martin Langhoff wrote:
> If the two branches are related, and you want the imported git
> branches to be related, do
>
> git-archimport arch-eduforge@catalyst.net.nz--2004/scripts
>
> that will bring all the stuff under scripts. If there are other
> branches or projects there that aren't related or you don't want to
> pull, do
>
> git-archimport arch-eduforge@catalyst.net.nz--2004/scripts--base \
> arch-eduforge@catalyst.net.nz--2004/scripts--oco
>
> In any case, you shoud never pass the last token (base-0). Also, if
> you have filenames with spaces or funny chars, you'll want a patch
> that I'm about to post.
>
> If you don't mind having this discussion on git@vger, could you
> forward it there?
>
> cheers,
>
>
> martin
>
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > hello, I was trying out the git-archimport script, I have a question.
> >
> > say I have two branches in tla (in the same archive):
> >
> > scripts--base--0
> > scripts--oco--0
> >
> > and scripts--oco--0--base-0 was tagged from scripts--base--0--patch-2.
> >
> > I first tried importing only the base branch, that worked fine. then
> > I started a new directory, and tried this:
> >
> > git arch-import -v archive/scripts--base--0 archive/scripts--oco--0
> >
> > and it keeps complaning about not being able to find scripts--oco--0--
> > patch-1. patch-1 is just a regular commit in the tla archive.
> > (patch-2 and patch-3 are merges from scripts--base)
> >
> > anyway, am I understanding the paradigm of the git-archimport script?
> > that I should expect it to be able to create a git repository for me
> > from these 2 branches?
> >
> > thanks for any info
> >
>
^ permalink raw reply
* Re: Do I misunderstand cg-merge --squash option
From: Petr Baudis @ 2005-11-10 21:16 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511102036.06484.alan@chandlerfamily.org.uk>
Dear diary, on Thu, Nov 10, 2005 at 09:36:06PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> On Thursday 10 Nov 2005 19:29, Petr Baudis wrote:
>
> >
> > Right now, what about trying to manually select the merge base?
> >
> > public$ cg-merge -b v1.0 master
>
> Actually, that does merge very nicely. However, I don't think its what I
> want. From gitk I get both routes back to my initial commit, both the fast
> track one and the slow train via all stations en-route.
>
> I have had more success with grafting (which you kindly informed me about
> yesterday)
>
> something like
>
> echo `cg-object-id v1.0` `cg-object-id initial_commit` >.git/info/grafts
>
> lf I make a branch out of the parent of v1.0 before doing this, I end up with
> there being a side branch of the old history and my master branch headed back
> through a quick route to the initial_commit.
Huh. But you still have the history cluttered and both routes to your
initial commit, don't you? I'm now confused - I fear I don't know what
you want anymore. But well, whatever is working out for you... ;-)
> Something strange (well actually not that unexpected, the more I think about
> it) has happened though.
>
> I was trying to see if cg-clone would effectively me make a new repository
> without the grafts in it (ie with real commit object with a parent as
> specified via the graft) but it doesn't - it just looses the graft and
> rebrings all the old history back in
>
> Is that a bug?
So far grafts were considered a private thing to enable some cool things
like tying ancient history to your current history tree, etc. But if you
want to do some persistent changes in the DAG, you are really best off
just rebuilding the whole history.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] cg-log: ignore merges by default, and add --show-merges option
From: Frank Sorenson @ 2005-11-10 21:03 UTC (permalink / raw)
To: Petr Baudis, Git Mailing List
In-Reply-To: <4373B1A6.8000706@tuxrocks.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This patch allows cg-log to ignore merges by default,but will display
them if requested (with "--show-merges").
Signed-off-by: Frank Sorenson <frank@tuxrocks.com>
cg-log | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/cg-log b/cg-log
index 7d955e3..ed2278e 100755
- --- a/cg-log
+++ b/cg-log
@@ -58,6 +58,9 @@
# by their author. This is also known as a "shortlog", suitable
# e.g. for contribution summaries of announcements.
#
+# --show-merges::
+# Display merges in the log as well (ignored by default).
+#
# -uUSERNAME::
# List only commits where author or committer contains 'USERNAME'.
# The search for 'USERNAME' is case-insensitive.
@@ -255,6 +258,7 @@ user=
mergebase=
date_from=
date_to=
+no_merges="--no-merges"
while optparse; do
if optparse -c; then
@@ -300,6 +304,8 @@ while optparse; do
summary=1
elif optparse --summary; then
shortlog=1
+ elif optparse --show-merges; then
+ no_merges=""
else
optfail
fi
@@ -315,9 +321,9 @@ if [ "$mergebase" ]; then
fi
if [ "$shortlog" ]; then
- - revls="git-rev-list --pretty=short $date_from $date_to"
+ revls="git-rev-list --pretty=short $no_merges $date_from $date_to"
else
- - revls="git-rev-list --pretty=raw $date_from $date_to"
+ revls="git-rev-list --pretty=raw $no_merges $date_from $date_to"
fi
revls="$revls $date_from $date_to"
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDc7WOaI0dwg4A47wRAsPuAJ0W0s82jfxu+c/oHRPULaa5l9ITagCdEkhz
NZAE2w8SnNbHl3/8MDtFT3w=
=4cRS
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-10 20:48 UTC (permalink / raw)
To: Andreas Ericsson, Jim Radford; +Cc: git
In-Reply-To: <4373AE02.9050909@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Jim Radford wrote:
>> On Thu, Nov 10, 2005 at 12:14:29AM -0800, Junio C Hamano wrote:
>>
>>> I think archimport part needs to be split out just like its
>>> svn/cvs cousins,
>> I don't agree...
>
> How is this different for when svnimport and cvsimport was moved out?..
>
>> The main reason I see for splitting cvs and email import out is the
>> non-standard dependencies, cvsps and perl(Email::Valid).
>
> Define "non-standard". String::ShellQuote isn't installed by default on
> Fedora Core 3 but is required by git-archimport.
I am with Andreas here.
If you are using git to manage development in a tightly knitted
group (e.g. company internal project) and are unlikely to be
exchanging email patches, not having to pull Email::Valid into
your system is a good thing, because you would not be using
git-mail. If you are not dealing with development history
stored in svn or tla, not having to install git-svn nor git-tla
is a good thing.
Technical reasons like package availablity and required package
size count, but I do not think we should be doing the split
purely for technical reasons. The split should aim primarily
to give convenience for the users.
That reminds me, Andreas, you said something about feeding me
spec updates last week but Jim beated you. I am open to
improvements from both of you. Obviously the invitation is not
limited to two of you ;-).
^ permalink raw reply
* [PATCH] cg-log: add --no-merges option to be passed to git-rev-list
From: Frank Sorenson @ 2005-11-10 20:46 UTC (permalink / raw)
To: Petr Baudis, Git Mailing List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This patch allows cg-log to ignore merges.
Signed-off-by: Frank Sorenson <frank@tuxrocks.com>
cg-log | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/cg-log b/cg-log
index 7d955e3..2cebf04 100755
- --- a/cg-log
+++ b/cg-log
@@ -58,6 +58,9 @@
# by their author. This is also known as a "shortlog", suitable
# e.g. for contribution summaries of announcements.
#
+# --no-merges::
+# Don't display merges in the log.
+#
# -uUSERNAME::
# List only commits where author or committer contains 'USERNAME'.
# The search for 'USERNAME' is case-insensitive.
@@ -255,6 +258,7 @@ user=
mergebase=
date_from=
date_to=
+no_merges=
while optparse; do
if optparse -c; then
@@ -300,6 +304,8 @@ while optparse; do
summary=1
elif optparse --summary; then
shortlog=1
+ elif optparse --no-merges; then
+ no_merges="--no-merges"
else
optfail
fi
@@ -315,9 +321,9 @@ if [ "$mergebase" ]; then
fi
if [ "$shortlog" ]; then
- - revls="git-rev-list --pretty=short $date_from $date_to"
+ revls="git-rev-list --pretty=short $no_merges $date_from $date_to"
else
- - revls="git-rev-list --pretty=raw $date_from $date_to"
+ revls="git-rev-list --pretty=raw $no_merges $date_from $date_to"
fi
revls="$revls $date_from $date_to"
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDc7GmaI0dwg4A47wRAosOAJ4k7ObTH9dc0me1SEGZFib0KsceqQCdHxX8
w7WXZzCR5dLKgyA0LV49YFU=
=6kA3
-----END PGP SIGNATURE-----
^ permalink raw reply
* Getting rid of symlinks in .git?
From: Petr Baudis @ 2005-11-10 20:45 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
I'm deliberately breaking up the thread here, not to make the list
reading even more difficult for all the poor readers not so interested
in electronic archaeology (but I feel better after I began taking my
new meds, I can even resist this huge urge to start replying to mails
from June).
In-Reply-To: <1131653507.11283.31.camel@dv>
7261 N T Nov 10 Pavel Roskin ( 1.8K)
Re: [PATCH] cg-pull to stop treating "master" specially,
fix fetch_local for .git/HEAD
(deliberately quoted in entirety)
Dear diary, on Thu, Nov 10, 2005 at 09:11:47PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Thu, 2005-11-10 at 20:24 +0100, Petr Baudis wrote:
> > can you still remember why did you introduce this? In GNU cp
> > documentation, I can see just
> >
> > -b, --backup
> > Make backups of files that are about to be overwritten or removed.
> >
> > which doesn't make sense to me - -L dereferences symlinks.
>
> You are right, it must be my error. Anyway, it was so long ago that I
> would need to review and retest it.
Is it correct that all there is to it is to check if cloning locally
works properly with symlinked HEAD in the remote repository?
> While at that, let's stop using symlinks. git doesn't use symlinks on
> Cygwin. I think git should use that code on all OSes, since the
> benefits of using symlinks are minimal (I think the only benefits are
> their atomicity and resolving the reference in the kernel rather than in
> userspace). Having more uniform code for all platforms would simplify
> development and testing. It could also reduce requirements for the
> transport protocols. Finally, symlinks could be still used by the users
> (if they know what they are doing) - git and cogito would simply become
> symlink agnostic.
>
> When files are copied around, symlinks are pain to deal with. They
> require special handling to be preserved both for remote operation and
> dereferenced for local operation (that's what my patch was intended to
> do). I'm not even considering what would happen when cloning from Linux
> to Windows or vice versa.
I personally would not mind getting rid of symlinks completely, but we
will still have to support them for some reasonable time period (several
major releases, as far as Cogito is concerned - actually, there is
plenty of people still using 0.13 and such).
If more people think this is good idea, I could even again introduce
some compatibility code to cg-Xlib which will rewrite symlinkish HEAD
when it hits it (the kind of stuff we did in the old times).
> Sure, it can wait until git 1.0, but it would be great to keep this goal
> in mind.
>
> Disclaimer - I'm not reading the git mailing list, so if it was
> discussed, I'm sorry, I don't intend to restart that discussion - just
> give me the pointer and I'll read it.
I didn't notice such a discussion yet.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Do I misunderstand cg-merge --squash option
From: Alan Chandler @ 2005-11-10 20:36 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20051110192923.GT30496@pasky.or.cz>
On Thursday 10 Nov 2005 19:29, Petr Baudis wrote:
>
> Right now, what about trying to manually select the merge base?
>
> public$ cg-merge -b v1.0 master
Actually, that does merge very nicely. However, I don't think its what I
want. From gitk I get both routes back to my initial commit, both the fast
track one and the slow train via all stations en-route.
I have had more success with grafting (which you kindly informed me about
yesterday)
something like
echo `cg-object-id v1.0` `cg-object-id initial_commit` >.git/info/grafts
lf I make a branch out of the parent of v1.0 before doing this, I end up with
there being a side branch of the old history and my master branch headed back
through a quick route to the initial_commit.
Something strange (well actually not that unexpected, the more I think about
it) has happened though.
I was trying to see if cg-clone would effectively me make a new repository
without the grafts in it (ie with real commit object with a parent as
specified via the graft) but it doesn't - it just looses the graft and
rebrings all the old history back in
Is that a bug?
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: merge-one-file: use common as base, instead of emptiness.
From: Petr Baudis @ 2005-11-10 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6fgxn28.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 10, 2005 at 09:30:55PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > But obviously now the trouble is opposite, when the files are completely
> > unrelated, since now you likely get large conflicting areas interleaved
> > with some scarce common lines... And this might get to be a big PITA to
> > resolve as well.
>
> Yeah, you can always count lines in $orig and $src2 after
> two-file merge runs, and if it appears we do not have enough
> common section just empty the $orig before running merge.
Reasonable solution, I like that. Let's say 50%, like for the renames
detection?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ 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