* finding similar blobs (was: Re: $Revision$ keyword replacement?
From: Junio C Hamano @ 2005-11-22 22:42 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <871x18h9ee.fsf@ifae.es>
Santi Béjar <sbejar@gmail.com> writes:
> How similar this file is to the file $path in these commit(s)?
Very cute.
> tmp=`mktemp -t -d git-find-sim.XXXXXXX`
> ...
> git update-index --add $file || exit 1
> tree=`git-write-tree`
Are you going through all this trouble just to avoid a blob and
a tree object left dangling after you are done? Or is there
something else going on?
> rev_arg=`GIT_DIR=$GIT_DIR_ORIG git-rev-parse --default HEAD --revs-only "$@"`
> revs=`GIT_DIR=$GIT_DIR_ORIG git-rev-list $rev_arg`
> for i in $revs; do
> git diff-tree --name-status $i -C $tree | grep $file |
> sed "s/^/$i:/"
> done
Perhaps
GIT_DIR=$GIT_DIR_ORIG git-rev-list $rev_arg |
while read one
git diff-tree --name-status -r $one -C $tree | grep $file |
sed "s/^/$one:/"
done
just in case the similar file you will discover is hidden in a
subdirectory?
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Lukas Sandström @ 2005-11-22 22:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Alex Riesen, Lukas Sandström
In-Reply-To: <7vek58ct4b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>
>>Subject: [PATCH] speedup allocation in pack-redundant.c
>>
>>Reuse discarded nodes of llists
>>
>>Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
>
>
> I think making allocation/deallocation to the central place is a
> good cleanup, but I am not sure about the free-nodes reusing.
> Does this make difference in real life? If so, it might be
> worth doing the slab-like allocation, since free-nodes are very
> small structure and malloc overhead is not ignorable there.
>
>
I have done some tests, and unfortunatley I saw approx. zero
improvement with Alex's patch. (less than 10ms difference when
total runtime is 1.850s, tested on http://home.arcor.de/fork0/download/idx.tar.gz)
Did someone else notice an improvement?
It's a nice idea though. I'll look into doing slab-allocation
for the fun of it, but I'm not really sure that malloc is the
bottleneck.
/Lukas
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Alex Riesen @ 2005-11-22 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lukas Sandström, git
In-Reply-To: <7vek58ct4b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Tue, Nov 22, 2005 21:41:56 +0100:
> > Reuse discarded nodes of llists
> >
> > Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
>
> I think making allocation/deallocation to the central place is a
> good cleanup, but I am not sure about the free-nodes reusing.
> Does this make difference in real life?
It definitely does, though nor very much. I have no real numbers at
hand (being home now), but I remember it was 1 min with against 3 min
without the patch on cygwin+fat32, which is already bad enough all by
itself. Very big repository with no redundant packs in it.
> If so, it might be worth doing the slab-like allocation, since
> free-nodes are very small structure and malloc overhead is not
> ignorable there.
Like this?
if ( free_nodes ) { ... }
else {
struct llist_node *slab = malloc(sizeof(*slab) * BLKCNT);
for ( i =0; i < BLKCNT; ++i ) {
slab->next = free_nodes;
free_nodes = slab++;
}
}
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Josef Weidendorfer @ 2005-11-22 23:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511221854120.27872@wbgn013.biozentrum.uni-wuerzburg.de>
On Tuesday 22 November 2005 18:56, Johannes Schindelin wrote:
> On Tue, 22 Nov 2005, Josef Weidendorfer wrote:
> > [remote:origin]
> > url = master.kernel.org:/pub/scm/git/git.git
> > pull = master:origin
> I don't know if you missed it, but hierarchical config keys were
> introduced by b17e659dd4007cb1d3eb5ac32b524c0c5ab59601:
>
> [remote.origin]
> url = master.kernel.org:/pub/scm/git/git.git
> pull = master:origin
I know. My suggestion complements hierarchical keys:
[myporcelain.headproperties: my/head.name]
merge.candidates = my/other.head
merge.default = your/master
would be the same as
[myporcelain.headproperties]
merge.candidates = my/other.head for my/head.name
merge.default = your/master for my/head.name
It is about specifying the same " for "-part for multiple keys.
The idea is to use everything after a ":\s*" in a section name
to use as prefix for any " for "-part of keys values given in
this section.
Josef
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Junio C Hamano @ 2005-11-22 23:08 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <4383A053.8020100@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> Did someone else notice an improvement?
Not me. I merged it only for its clean-up value, not immediate
performance reasons.
^ permalink raw reply
* Re: finding similar blobs (was: Re: $Revision$ keyword replacement?
From: Santi Bejar @ 2005-11-22 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy83gb8zk.fsf@assigned-by-dhcp.cox.net>
2005/11/22, Junio C Hamano <junkio@cox.net>:
> Santi Béjar <sbejar@gmail.com> writes:
>
>
> > tmp=`mktemp -t -d git-find-sim.XXXXXXX`
> > ...
> > git update-index --add $file || exit 1
> > tree=`git-write-tree`
>
> Are you going through all this trouble just to avoid a blob and
> a tree object left dangling after you are done? Or is there
> something else going on?
No, there is nothing else. These are "easy" avoided, so why have these
dangling {blob,tree,...}s?
>
> > rev_arg=`GIT_DIR=$GIT_DIR_ORIG git-rev-parse --default HEAD --revs-only "$@"`
> > revs=`GIT_DIR=$GIT_DIR_ORIG git-rev-list $rev_arg`
> > for i in $revs; do
> > git diff-tree --name-status $i -C $tree | grep $file |
> > sed "s/^/$i:/"
> > done
>
> Perhaps
>
> GIT_DIR=$GIT_DIR_ORIG git-rev-list $rev_arg |
> while read one
> git diff-tree --name-status -r $one -C $tree | grep $file |
> sed "s/^/$one:/"
> done
>
> just in case the similar file you will discover is hidden in a
> subdirectory?
Oops :)
Santi
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Lukas Sandström @ 2005-11-22 23:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20051122230011.GA2916@steel.home>
Alex Riesen wrote:
> Junio C Hamano, Tue, Nov 22, 2005 21:41:56 +0100:
>>I think making allocation/deallocation to the central place is a
>>good cleanup, but I am not sure about the free-nodes reusing.
>>Does this make difference in real life?
>
>
> It definitely does, though nor very much. I have no real numbers at
> hand (being home now), but I remember it was 1 min with against 3 min
> without the patch on cygwin+fat32, which is already bad enough all by
> itself. Very big repository with no redundant packs in it.
>
Would you mind sharing the .idx files?
^ permalink raw reply
* Re: Question about handling of heterogeneous repositories
From: Alex Riesen @ 2005-11-22 23:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43837442.9060602@op5.se>
Andreas Ericsson, Tue, Nov 22, 2005 20:40:50 +0100:
> >it is sometimes the case that a project consists of parts which are
> >unrelated to each other, and only thing in common between them is that
> >they all are used in that particular project. For example a program
> >uses some library and the developer(s) of that program would like to
> >have the source of that library somewhere close. Well, for this simple
> >example one could just use two repositories, laid close to each other
> >in a directory, like project/lib and project/prog.
> >Now, if I make the example a bit more complex and say, that the
> >developers of the program are the developers in that project and
> >change everything under project/ directory, including
> >project/library/. They are also good people and ready to give the
> >changes to the library upstream.
> >
> >How do they achieve that, without sending project/ and project/program/?
> >
> >For everyone who have an experience with ClearCase or Perforce (I'm
> >sorry for mentioning it) it is what the "mappings" are often used for:
> >a project is build together from different parts, which can be worked
> >on separately.
> >
> >I'm trying to introduce git at work, but have to prepare myself for
> >possible questions first, and this is one of them :)
> >
>
> We do like this;
>
> core
> core/gui
> core/lib
>
> $ cat .gitignore
> gui
> lib
>
> This is also nice because it lets the gui maintainers have the gui as
> the root with the core and lib parts as subdirectories. Everyone has
> their own responsibility checked out at top-level with other pieces
> below it. It's easy enough to script a pull of all repos so everyone's
> up to sync and everybody's happy.
And than, do you have to announce a special procedure everyone's is to
execute after a clone so all subrepos are cloned? How do you handle
common configs and clone options in subrepos? It also would be nice to
have branches visible not only in in subrepos but in top-repo as well,
and the other way around.
I'm also wondering, what implications core/lib/.git/{config,remotes/,refs/}
under control in core/ can have?..
> It would certainly be nicer to have git ignore directories that have the
> ".git" directory (so long as it's not the top of the repo, that is), but
> I haven't had the energy to fix that when there's already a solution
> that's simple enough and quite adequate.
BTW, will something like "*/.git/*" in info/exclude work? IOW, does *
match a "/"?
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Alex Riesen @ 2005-11-22 23:38 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano
In-Reply-To: <4383A66D.2030201@etek.chalmers.se>
Lukas Sandström, Wed, Nov 23, 2005 00:14:53 +0100:
> >>I think making allocation/deallocation to the central place is a
> >>good cleanup, but I am not sure about the free-nodes reusing.
> >>Does this make difference in real life?
> >
> > It definitely does, though nor very much. I have no real numbers at
> > hand (being home now), but I remember it was 1 min with against 3 min
> > without the patch on cygwin+fat32, which is already bad enough all by
> > itself. Very big repository with no redundant packs in it.
>
> Would you mind sharing the .idx files?
this time I probably would (they're not here)... But for a perfomance
testing any big repository will do, linux kernel, for example.
^ permalink raw reply
* Re: finding similar blobs (was: Re: $Revision$ keyword replacement?
From: Junio C Hamano @ 2005-11-22 23:40 UTC (permalink / raw)
To: Santi Bejar; +Cc: git
In-Reply-To: <8aa486160511221510v667dbfd5y@mail.gmail.com>
Santi Bejar <sbejar@gmail.com> writes:
> No, there is nothing else. These are "easy" avoided, so why have these
> dangling {blob,tree,...}s?
Only because I am lazy ;-).
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Alex Riesen @ 2005-11-22 23:46 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git, Junio C Hamano
In-Reply-To: <4383A053.8020100@etek.chalmers.se>
Lukas Sandström, Tue, Nov 22, 2005 23:48:51 +0100:
> >>Subject: [PATCH] speedup allocation in pack-redundant.c
> >>Reuse discarded nodes of llists
> >>Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
> >
> > I think making allocation/deallocation to the central place is a
> > good cleanup, but I am not sure about the free-nodes reusing.
> > Does this make difference in real life? If so, it might be
> > worth doing the slab-like allocation, since free-nodes are very
> > small structure and malloc overhead is not ignorable there.
> >
> I have done some tests, and unfortunatley I saw approx. zero
> improvement with Alex's patch. (less than 10ms difference when
> total runtime is 1.850s, tested on http://home.arcor.de/fork0/download/idx.tar.gz)
Can I suggest you try it in a really really weird environment? Like
Cygwin. And switch some virus scanner on.
> Did someone else notice an improvement?
My test case had over 100k files in it (just don't ask why. Weird
environments, weird projects, ...)
> It's a nice idea though. I'll look into doing slab-allocation
> for the fun of it, but I'm not really sure that malloc is the
> bottleneck.
Yes, it usually is not a bottleneck. I think, it just another
exception.
^ permalink raw reply
* Re: [PATCH] speedup allocation in pack-redundant.c
From: Lukas Sandström @ 2005-11-22 23:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20051122233845.GC2916@steel.home>
Alex Riesen wrote:
> Lukas Sandström, Wed, Nov 23, 2005 00:14:53 +0100:
>
>>>>I think making allocation/deallocation to the central place is a
>>>>good cleanup, but I am not sure about the free-nodes reusing.
>>>>Does this make difference in real life?
>>>
>>>It definitely does, though nor very much. I have no real numbers at
>>>hand (being home now), but I remember it was 1 min with against 3 min
>>>without the patch on cygwin+fat32, which is already bad enough all by
>>>itself. Very big repository with no redundant packs in it.
>>
>>Would you mind sharing the .idx files?
>
>
> this time I probably would (they're not here)... But for a perfomance
> testing any big repository will do, linux kernel, for example.
>
The problem is that the large repository I have contains lots of
redundant packs, which makes quite fast to find a complete set
and end the search. If you don't have any redundant packs, the
complete set search really is 2**n (n = the number of packs).
I did some quick experiments with slab allocation and got a 4.4%
improvement on the redundant repo, so that might be worth persuing.
(Concept patch below)
diff --git a/pack-redundant.c b/pack-redundant.c
index b38baa9..05294f8 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -8,6 +8,8 @@
#include "cache.h"
+#define BLKSIZE 1024
+
static const char pack_redundant_usage[] =
"git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | <.pack filename> ...>";
@@ -38,24 +40,28 @@ struct pll {
static struct llist_item *free_nodes = NULL;
+static inline void llist_item_put(struct llist_item *item)
+{
+ item->next = free_nodes;
+ free_nodes = item;
+}
+
static inline struct llist_item *llist_item_get()
{
struct llist_item *new;
if ( free_nodes ) {
new = free_nodes;
free_nodes = free_nodes->next;
- } else
- new = xmalloc(sizeof(struct llist_item));
-
+ } else {
+ int i = 1;
+ new = xmalloc(sizeof(struct llist_item) * BLKSIZE);
+ for(;i < BLKSIZE; i++) {
+ llist_item_put(&new[i]);
+ }
+ }
return new;
}
-static inline void llist_item_put(struct llist_item *item)
-{
- item->next = free_nodes;
- free_nodes = item;
-}
-
static void llist_free(struct llist *list)
{
while((list->back = list->front)) {
^ permalink raw reply related
* gitweb on kernel.org and UTF-8
From: Junio C Hamano @ 2005-11-23 0:03 UTC (permalink / raw)
To: git
Is it possible that the UTF-8 check in gitweb running on
kernel.org machine is somehow too strict?
The following two commits in git.git repository are not showing
properly.
I have a track record of getting peoples' names wrong, so I
double checked my commit objects, and as far as I can tell, all
of them are encoded in UTF-8 properly (or at least I can view
what I expect if I throw raw bytes from the commit objects at my
Firefox):
c3df8568424684bbcc7df7722eb3ec34bdae8b2d
This is from Yoshifuji-san; the third character in
author name field is mangled.
bb931cf9d73d94d9940b6d0ee56b6c13ad42f1a0
This is from Lukas Sandstr*m; o with Umlaut on top is
showing a ?. Incidentally, the blob that records recent
version of Documentation/git-pack-redundant.txt has his
name in it, which has the same ? problem, but "plain"
option shows his name correctly in UTF-8.
Interestingly enough, my name spelled in Japanese
(Documentatino/git-lost-found.txt) is intact. Am I getting a
VIP treatment somehow?
^ permalink raw reply
* Re: [PATCH] Add git-graft-ripple, a tool for permanently grafting history into a tree.
From: Linus Torvalds @ 2005-11-23 0:55 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <11326926501602-git-send-email-ryan@michonline.com>
On Tue, 22 Nov 2005, Ryan Anderson wrote:
>
> Enhancements over the original example:
>
> o Each newly created commit A' references A, and (A^1)' (The first try
> referenced A^1 and (A^1)' but not A)
>
> o Support for incrementally rewriting history is present.
How about the case of having commits that have pointers to other commits
in the comments?
For example, on the kernel do
gitk 19842d67340e4a8f616552d344e97fc7452aa37a
and see how gitk highlights the SHA1's in the commit message and makes
hyperlinks to the commits they point to..
Linus
^ permalink raw reply
* Re: [PATCH 4/6] Add check_repo_format check for all major operations.
From: Junio C Hamano @ 2005-11-23 0:57 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <7vd5ksefth.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Yes, although that is exactly what I said "this does not quite
> feel right" ;-). Is it hard to arrange things so that a process
> does exactly one check_repo_format() during its lifetime?
Let's back up a bit. I'll deal with only low-level commands
here.
First, the easiest group. The following commands do not look at
the repository (.git directory) at all.
check-ref-format get-tar-commit-id git index-pack mailinfo
mailsplit patch-id shell show-index stripspace verify-pack
We do not need to do anything special about them.
The following three use enter_repo() to the given path (either
from the end user at the command line or over the network):
daemon receive-pack upload-pack
The repo format check should be done at the same place as we
make sure enter_repo() finds the given directory a satisfactory
path. That is, just before putenv(GIT_DIR=.) in enter_repo().
The following use setup_git_directory(), which chdir()s to the
toplevel unless GIT_DIR is set.
cat-file config-set diff-files diff-index diff-stages diff-tree
ls-files name-rev rev-list rev-parse show-branch symbolic-ref
update-index update-ref
Maybe we can have a thin wrapper around setup_git_directory()
and after it returns check "${GIT_DIR-.git}" for repository
format mismatch. What to do when GIT_DIR is set? Then we can
just use it to read the config from "$GIT_DIR/config" and check
the version.
The following commands implicitly assume that they are either
run from the toplevel or GIT_DIR environment tells them where
the .git/ directory is:
apply checkout-index clone-pack commit-tree convert-objects
fetch-pack fsck-objects hash-object http-fetch http-push init-db
local-fetch ls-tree merge-base merge-index mktag pack-objects
pack-redundant peek-remote prune-packed read-tree send-pack
ssh-fetch ssh-upload tar-tree unpack-file unpack-objects
update-server-info var write-tree
With some exceptions, they are pretty much repository wide
commands, so I think it is OK for them to assume they start at
the toplevel (the Porcelain would chdir to the top for them
otherwise). The ones that take paths, namely, checkout-index,
hash-object and ls-tree, may want to use setup_git_directory()
and do the path prefixing.
That means we would need to have some way for the rest of the
commands to check if "${GIT_DIR-.git}" is of the right format
version, and call that *once* per process invocation,
perferrably at the beginning of the main().
We need an access to .git/config file to do the repository
format check anyway, which means we need setup_git_directory()
if we ever want to run them from subdirectories. And running
setup_git_directory() from the toplevel would not hurt, so
perhaps if we add setup_git_directory() at the beginning of
main() for the "implicity toplevel" class, and rewrite
setup_git_directory() like this:
static const char *setup_git_directory_main(void)
{
/* current setup_git_driectory() */
}
const char *setup_git_directory(void)
{
const char *retval = setup_git_directory_main();
check_repository_format_version(); /* dies on mismatch */
return retval;
}
it _might_ be good enough.
I said "it _might_" here, because we need to be careful. Right
now, if you run the "implicitly toplevel" commands from a
subdirectory, they fail. Some Porcelains and scripts may be
relying on that and there will be consequences if things
suddenly start not to fail but do something unexpected in higher
directories.
^ permalink raw reply
* Re: gitweb on kernel.org and UTF-8
From: H. Peter Anvin @ 2005-11-23 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmnw9qo0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Is it possible that the UTF-8 check in gitweb running on
> kernel.org machine is somehow too strict?
>
> The following two commits in git.git repository are not showing
> properly.
>
> I have a track record of getting peoples' names wrong, so I
> double checked my commit objects, and as far as I can tell, all
> of them are encoded in UTF-8 properly (or at least I can view
> what I expect if I throw raw bytes from the commit objects at my
> Firefox):
>
> c3df8568424684bbcc7df7722eb3ec34bdae8b2d
>
> This is from Yoshifuji-san; the third character in
> author name field is mangled.
>
> bb931cf9d73d94d9940b6d0ee56b6c13ad42f1a0
>
> This is from Lukas Sandstr*m; o with Umlaut on top is
> showing a ?. Incidentally, the blob that records recent
> version of Documentation/git-pack-redundant.txt has his
> name in it, which has the same ? problem, but "plain"
> option shows his name correctly in UTF-8.
>
> Interestingly enough, my name spelled in Japanese
> (Documentatino/git-lost-found.txt) is intact. Am I getting a
> VIP treatment somehow?
>
I think it's missing a "binmode STDOUT, ':utf8';" somewhere...
For what it's worth, I looked at both the above examples and the binary
encoding in the git repository is undoubtedly correct; the two
characters are U+82F1/E8 8B B1 (英) and U+00F6/C3 B6 (ö) respectively,
both of which are 100% valid UTF-8.
-hpa
^ permalink raw reply
* pack-redundant.c:689: warning: long unsigned int format, size_t arg (arg 3)
From: Morten Welinder @ 2005-11-23 1:34 UTC (permalink / raw)
To: GIT Mailing List
Maybe cast the size to unsigned long to make it match the format.
M.
pack-redundant.c: In function `main':
pack-redundant.c:689: warning: long unsigned int format, size_t arg (arg 3)
^ permalink raw reply
* Re: pack-redundant.c:689: warning: long unsigned int format, size_t arg (arg 3)
From: H. Peter Anvin @ 2005-11-23 1:46 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc0511221734r33b20f6au97fe2e93243f5ccf@mail.gmail.com>
Morten Welinder wrote:
> Maybe cast the size to unsigned long to make it match the format.
>
> M.
>
> pack-redundant.c: In function `main':
> pack-redundant.c:689: warning: long unsigned int format, size_t arg (arg 3)
Or use %zu for the format.
-hpa
^ permalink raw reply
* Re: pack-redundant.c:689: warning: long unsigned int format, size_t arg (arg 3)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-11-23 0:49 UTC (permalink / raw)
To: hpa; +Cc: mwelinder, git, yoshfuji
In-Reply-To: <4383CA08.4080604@zytor.com>
In article <4383CA08.4080604@zytor.com> (at Tue, 22 Nov 2005 17:46:48 -0800), "H. Peter Anvin" <hpa@zytor.com> says:
> Morten Welinder wrote:
> > Maybe cast the size to unsigned long to make it match the format.
> >
> > M.
> >
> > pack-redundant.c: In function `main':
> > pack-redundant.c:689: warning: long unsigned int format, size_t arg (arg 3)
>
> Or use %zu for the format.
It is not widely supported, I think.
--yoshfuji
^ permalink raw reply
* Problem merging
From: Luben Tuikov @ 2005-11-23 2:50 UTC (permalink / raw)
To: git
Ok, background:
I've two branches of the same .git, _but_ they live in
different directories (bearing the branches' names)
with different index caches, but with the same identical
objects directory (different HEADs of course).
(in effect, I have both branches "checked out")
Branch A is the "trunk", branch B is trunk+my changes.
I do:
branchA: git pull <remote>
branchA: cd ../branchB/
branchB: git resolve HEAD branchA "merge trunk"
And I get:
Trying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into
e1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43.
Simple merge failed, trying Automatic merge
Removing include/asm-um/ldt.h
fatal: merge program failed
Automatic merge failed, fix up by hand
This is with git HEAD:
2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as
of now.
Is this a bug in git? Since this process has always worked
before.
Thanks,
Luben
^ permalink raw reply
* Re: Problem merging
From: Junio C Hamano @ 2005-11-23 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <20051123025001.15527.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Trying to merge 4b4a27dff4e2d4cc2eac1cde31aede834a966a48 into
> e1ef47b54d7e7e477f7f1eb3251a9d37f38e0469 using 989e4d6cbc69191c41ddf4b1c492457410376b43.
> Simple merge failed, trying Automatic merge
> Removing include/asm-um/ldt.h
> fatal: merge program failed
> Automatic merge failed, fix up by hand
>
> This is with git HEAD:
> 2392ee98eb76aa821de53c93c9e36acb18d27fc0 -- latest as
> of now.
>
> Is this a bug in git? Since this process has always worked
> before.
As "Merging two branches" section in Documentation/tutorial.txt
shows, it is one of the valid outcome from merge to leave
conflicts and have you manually resolve. So this process
probably is working correctly for you this time as well.
Sorry, but I am not a good enough cryptoanalyst to reverse SHA1
hashes, and I cannot tell if the merge you did *should* have
resulted in the conflict or not, just by looking at the three
commit object IDs.
What does "git diff" and "git diff HEAD" tell you after the
merge procedure leaves conflict in the working tree (branchB
directory, I mean)?
^ permalink raw reply
* Re: gitweb on kernel.org and UTF-8
From: Kay Sievers @ 2005-11-23 3:35 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Junio C Hamano, git
In-Reply-To: <4383BEE4.1060800@zytor.com>
On Tue, Nov 22, 2005 at 04:59:16PM -0800, H. Peter Anvin wrote:
> Junio C Hamano wrote:
> >Is it possible that the UTF-8 check in gitweb running on
> >kernel.org machine is somehow too strict?
> >
> >The following two commits in git.git repository are not showing
> >properly.
> >
> >I have a track record of getting peoples' names wrong, so I
> >double checked my commit objects, and as far as I can tell, all
> >of them are encoded in UTF-8 properly (or at least I can view
> >what I expect if I throw raw bytes from the commit objects at my
> >Firefox):
> >
> > c3df8568424684bbcc7df7722eb3ec34bdae8b2d
> >
> > This is from Yoshifuji-san; the third character in
> > author name field is mangled.
> >
> > bb931cf9d73d94d9940b6d0ee56b6c13ad42f1a0
> >
> > This is from Lukas Sandstr*m; o with Umlaut on top is
> > showing a ?. Incidentally, the blob that records recent
> > version of Documentation/git-pack-redundant.txt has his
> > name in it, which has the same ? problem, but "plain"
> > option shows his name correctly in UTF-8.
> >
> >Interestingly enough, my name spelled in Japanese
> >(Documentatino/git-lost-found.txt) is intact. Am I getting a
> >VIP treatment somehow?
> >
>
> I think it's missing a "binmode STDOUT, ':utf8';" somewhere...
>
> For what it's worth, I looked at both the above examples and the binary
> encoding in the git repository is undoubtedly correct; the two
> characters are U+82F1/E8 8B B1 (英) and U+00F6/C3 B6 (ö) respectively,
> both of which are 100% valid UTF-8.
Should be fine now. The escapeHTML() garbled the utf8 "ö", and the
decode() failed that.
Thanks,
Kay
^ permalink raw reply
* Re: Problem merging
From: Luben Tuikov @ 2005-11-23 3:41 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7v4q6483ms.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> What does "git diff" and "git diff HEAD" tell you after the
> merge procedure leaves conflict in the working tree (branchB
> directory, I mean)?
Apparently include/asm-um/ldt.h has been renamed
and this was giving problems.
I had to manually git-update-index --force-remove that
file and then git resolve worked ok.
Luben
^ permalink raw reply
* Re: gitweb on kernel.org and UTF-8
From: H. Peter Anvin @ 2005-11-23 3:42 UTC (permalink / raw)
To: Kay Sievers; +Cc: Junio C Hamano, git
In-Reply-To: <20051123033526.GA24098@vrfy.org>
Kay Sievers wrote:
>
> Should be fine now. The escapeHTML() garbled the utf8 "ö", and the
> decode() failed that.
>
Indeed, looks much better.
Now if I could only figure out why both Konsole and Firefox seems to use
a standalone cedilla to represent U+FFFD, instead of something more
logical like an inverted question mark or empty box.
-hpa
^ permalink raw reply
* [PATCH] gitk: UTF-8 support
From: Pavel Roskin @ 2005-11-23 4:15 UTC (permalink / raw)
To: git, Paul Mackerras
Add gitencoding variable and set it to "utf-8". Use it for converting
git-rev-list output.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/gitk b/gitk
index 3dd97e2..e53b609 100755
--- a/gitk
+++ b/gitk
@@ -19,7 +19,7 @@ proc gitdir {} {
proc getcommits {rargs} {
global commits commfd phase canv mainfont env
global startmsecs nextupdate ncmupdate
- global ctext maincursor textcursor leftover
+ global ctext maincursor textcursor leftover gitencoding
# check that we can find a .git directory somewhere...
set gitdir [gitdir]
@@ -49,7 +49,7 @@ proc getcommits {rargs} {
exit 1
}
set leftover {}
- fconfigure $commfd -blocking 0 -translation lf
+ fconfigure $commfd -blocking 0 -translation lf -encoding $gitencoding
fileevent $commfd readable [list getcommitlines $commfd]
$canv delete all
$canv create text 3 3 -anchor nw -text "Reading commits..." \
@@ -3657,6 +3657,7 @@ set datemode 0
set boldnames 0
set diffopts "-U 5 -p"
set wrcomcmd "git-diff-tree --stdin -p --pretty"
+set gitencoding "utf-8"
set mainfont {Helvetica 9}
set textfont {Courier 9}
--
Regards,
Pavel Roskin
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox