Hi,
I'm looking for the best path to import a bk repo into git.
I was not able to find the download site for the tailor repo-conversion application.

Is it still supported and maintained?
I think bk can export to CVS and then git can import from CVS.

Is this the best way?
Thanks in advance,
Scott
-

http://progetti.arstecnica.it/tailor/
i think so
- VMiklos

That's how I did my kernel history, and cvsps has a special "BK mode",

which knows to trust the CVS timestamps more when importing from a BK CVS

archive (since the timestamps will then be exact).
That said, the quality of the result isn't stellar. The CVS export will

obviously linearize the BK information, so you do lose things. So there's

actually a better kernel BK->git archive around which doesn't do that, but

that was done apparently from a custom database, so it's not reproducible.
			Linus

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
We have a CVS repository that we want to import into bitkeeper. I tried

the bk import option, including with a branch bug fix, but it's

still having problems.
I imported the CVS repository to git and it worked great. Since all

of our other repository are in bitkeeper the management would like to

stick with CVS. With git apparently still being weak in the area of

supporting difftool on different version that seems somewhat reasonable

for the time being.
The folks at bitmover are converting you kernels to bk and it's

maintaining the branch history and I'd like to do the same. So far

they haven't help us convert the git repository to bk. Do you happen

to know of someone else that might now how to do this in case the

folks at bitmover can't provide the scripts to convert this git

repository to bk?
I was curious why the difftool paradigm hasn't been integrated into

the git GUIs. It's very comfortable and I think it has been used in

other source code control systems, for example Sun Microsystems.
- -piet
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHE/pKJICwm/rv3hoRAs/QAJoDL0HQDaOAI1x6UakEiVvti9tI2wCfUpGI

bfyKH+ykUK7p2AL9CSE+XXc=

=0gnp

-----END PGP SIGNATURE-----

-

I can't see how bk's difftool could possibly have any relevance to the

"reasonable to stick with CVS" decision, but hey, I'm always surprised by

peoples inventiveness in rationalizing their decisions ;)
I don't know what difftool does that a simple
	git diff -U99 | viewdiff -
wouldn't do, but in all honesty, I don't think I ever used difftool (I

found the other tools in bk much more useful - eg mergetool, renametool)
I don't actually know of any sane programs to view unified diffs, but you

can script one with little trouble. Here's a really hacky one I just came

up with:
	#!/bin/sh

	cat "$@" > /tmp/diff

	grep '^[ -]' /tmp/diff > /tmp/orig

	grep '^[ +]' /tmp/diff > /tmp/result

	meld /tmp/orig /tmp/result
which fools 'meld' into showing a unified diff in a nice graphical manner.
[ Quite frankly, I don't understand why tools like meld and kdiff3 can't

  just take the unified diff directly - they have *all* the logic, it

  should be trivial to do, and very useful to view diffs for those people 
Hmm. Converting from git to bk should not be that hard at least

conceptually, but no, I have no idea how to script it sanely and

efficiently. The obvious solutions all would want to have multiple active

heads of development open at the same time (Larry calls them "LOD's" not

branches), and would also require some way to set the result of a merge.

Neither of which I would know how to do in BK (I created a lot of merges

in BK, but I always let BK do the merging - I wouldn't know how to specify

the merge result by hand).
		Linus

-

Kompare (KDE analog of meld) can. It is even bound to text/x-diff in

konqueror, so opening patches with konqueror yields side-by-side diff view.

On the other hand it still keeps a unixy behaviour:

 git diff | kompare -

works.
--=20

						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Side note: I think kompare is beautiful, but kompare does one thing

totally wrong: it seems to think that you only want to look at the diff

fragments one file at a time.
That's totally bogus. My trivial four-liner shell script does this better

than kompare does - as does "gitk" in the diff view window.
The fact is, quite often you have diffs that are lots of small changes to

tons of files, and the kompare interface is totally ludicrous and useless.

It would be *much* nicer to literally show them as one long flowing diff.
And yes, it will depend on circumstances, but I can't seem to even find

the config option to not do that. As a result, you have to click through

all the files manually (even the "Next file" thing is grayed out when I do

the "git diff | kompare -", so I can't even use the keyboard shortcut to

go to the next file).
So I have to say, after playing with it, my shell-script "viewdiff" is

actually infinitely better than "kompare -" is, at least for my workflow.
		Linus

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Wondering if adding a file dimension to gitk might help and adding the

ability to diff different version of a file git gitk by doing something
I just download 'meld', looks interesting, I didn't know about it or

'kompare'. Linking either one into gitk would be a pleasant graphical
Hmm, actually I'm only seeing rev topology up to 2.6.13,

later version seem to be linear and when I try to use a larger

time window something seems to crashing, the gui goes away,

and 'bk revtool' returns. Sigh.
I'll try keeping it real simple and just import our release branch

and hope for the best. Hopefully Johnannes, or perhaps folks more

involved with gitk can add a bit more graphical bling soon to the

cheetah release. BTW, is this the right mailing list for discussing

gitk as well as git?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFDPyJICwm/rv3hoRAsU0AJ9o6rHtu5rkiUeNlheRNUpwd4bfagCdHEK8

hDeVvRCyD8Xf8INbdMpuDDU=

=XB2c

-----END PGP SIGNATURE-----

-

In case you are interested a git GUI viewer called qgit can spawn

'Kompare' , 'Meld' or any other diff tool that support 'two files'

command line interface:
$my_preferred_diff_tool  file1.txt file2.txt
And they will show what you are looking for. The input files are

prepared by qgit that also handles the housekeeping at the end.
Another feature you asked, i.e. CTRL + right click to select a

revision (different from the parent) to diff against the current one

is also already implemented.
And of course the two above features can be integrated: you select two

random revisions and then call the external diff viewer to check at

the differences in the way you prefer.
It is possible to download qgit from
http://sourceforge.net/project/showfiles.php?group_id=139897
Two versions:
qgit-1.5.7 is Qt3 based
qgit-2.0 is Qt4 based (works also under Windows)
regards

Marco

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Marco Costalba wrote:
Hi Marco:
I've gone back and tried my old Qgit 1.5.3 and it was
While I'm looking at the diffs for a file if I pull down External Diff

it launches 'kcompare' but for a file with a large change it seems

to be running extremely slow. We have a file with 13,000 files in it

and I have two changes in the file, each is an addition and deletion

of about 100 lines in one contiguous block. If I click between them

it's fine but since the 100 lines is more than one page I try to

scroll thru the diff. At this point of time 'kompare' seems to be

using 95% of the CPU time and it takes about 10 seconds for it to

scroll. It scrolls fine in the qgit diff window. It;s not a problem

for small files. Know of what can me done so that 'kcompare' works

fast on large files; something like pointing it's tmp files to a

not NFS partition.
Another problem I've noticed is that sometime while running git

it seems to spend a large amount of time  switching from one

change-set to the next; seems to be due to all of the tagged
It seems that while I'm in "Rev List" mode I can select the the

two versions to compare a selected file with View->External diff...
Now, if I pull down "View File" or go to the file context were

you see the change-set for a file then I can't get the CTRL + right

click to allow me to diff two revisions of the file.
While messing around in this area of trying to diff two revision

of the file from the file context I got:

- ------------------------------------------------------------------

/nethome/piet/src/blux$ qgit

Saving cache. Please wait...

Compressing data...

Done.

Saving cache. Please wait...

Compressing data...

Done.

ASSERT in getAncestor: empty file from

e86306878efb575be80d070ac3dec49f8d358cd1

ASSERT in lookupAnnotation: no annotation for cli/quagga-0.96/lib/bluelane.c

ASSERT in remove: 8 is not the first in list

Thrown exception 'Canceling annotation'

Exception 'Canceling annotation' not ...
[ message continues ]

qgit does not intergarte Kompare functionality, it just prepares the

files and spawns a Kompare process.
So there's seem nothing qgit can do about Kompare speed. You can try
Well temporary file sfor Kompare are created in the repository working

directory. If this is a problem for you you can save manually the

files corresponding to the two revisions you want to diff (open tree

view, select the file, right click to open context menu, save as...)
You need to repeat the above 'save as...' the first time selecting the

first revision you want to compare, then selecting the other revision

in main view, so that tree view is updated and you end-up saving the

correct files.
You can save the files where you want then run Kompare manually, at
If you can post a repository where this occurs and the step to
It does not interfere wuth Qt3 also if you install with urpmi,

directories are kept separated. I have installed both with no
Qt4 is big and complex, I would really suggest avoid experimenting
In this case (and also in the above case of external viewer) you need

the magic wand ;-)
Select a file from tree view, go with the magic wand and you can do
Yes it is. qgit-1.5.7 should be very similar to qgit-2.0 regarding the

features you listed above.
Marco

-

You could avoid the temporary files if you just pipe the diff to kompare. That

would require an option to tell qgit that the external viewer can read a git diff.
At the time qgit 1.5 was written, kompare could not handle git diffs.
-- robin

-

So does the other tools I have checked at that time.
But I don't know if this fixes the problem of slowness reported. A

little test Pete may do is just as I have written in the former email:

try to save the big files that cause troubles where he prefers and run

Kompare on them directly from the command line.
Is kompare faster? If no probably the 'pipe' technique will not solve

the problem and shrinks the applicability of the external diff

launcher to tools that handle diffs directly.
Marco

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Marco:

   I'll try kcompare on the huge files both on and off the NFS

   file system to see if it has a noticeable impact.
Johannes:

  I read somewhere in the past week that it was possible to maintain

  our existing CVS environment with git. I though it was a separate

  package to export git back to cvs but I just noticed a git-cvsserver

  and as a std part of git and was wondering about using that.
  We have a number of build machines with flamebox perl scripts pulling

  out CVS branches for builds. I was wondering what is the best way to

  use git and it's nicer pull/push model and merge facility and possibly

  maintain CVS exports for scripts doing builds if possible the cvsweb

  and bonsai (CVS Query Form) that a number of engineers are currently

  using. I started looking over out flamebox scripts with the intent

  up converting them over to git but I mentioned the git to cvs

  coexistence and we are wondering if that's a better route than

  upgrading the flamebox scripts. Having our existing cvsweb, bonsai,

  and gitweb along with the git utilities seems at least desirable.

  Any thoughts or suggestions?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHF+8/JICwm/rv3hoRApKnAJ4suTVrULHeVnU2HrS3TDo+eTzxVQCbBH7x

NzKdc6wRc1VdAOWgXOXBJ4U=

=RuQc

-----END PGP SIGNATURE-----

-

If you do convert them to git, you can fairly easily do an automatic

bisect on build-errors, and the developer can (after some time) get

an email of what machines they broke the code on and what the bad

commit was.
Besides that, it's not a black-and-white scenario. If I were you I'd set

up git-cvsserver and make sure that works for all the scripts, and then

pick one or two auto-build things to convert to git. Preferrably on a

separate machine, so everything keeps working the same as always while

you're fiddling with the auto-build stuff.
Just my two cents.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Could you explain that a bit more. Sounds like you saying it's worth

messing with the flamebox scripts to use git instead of using the git

cvserver and letting them pull the cvs branches as they do now. Is the

existing flamebox email of build log effected buy switching form cvs
I get the impression your suggestion to first get git-cvsserver serving

the repo so that the build machines works without any change and then to

go to each build machine and update the scripts to use git instead of cvs.
Are there any tricks I need to so on the repo to make the branches pull

out with exactly the same commands that we are currently using. My guess
Hey, you two cents could easily save me hours of messing getting this

conversion done.
BTW, I don't think anyone is checking into the repo, but if they do

can I do another git-cvsimport to just update the one I already did?
- -piet
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGHUUJICwm/rv3hoRArHsAJ9GQMjpLc5CzpBXnHkxLfBgfwEo/QCdGNfj

DiivgfDDSbIB+9YBZvj/5Z0=

=SBSg

-----END PGP SIGNATURE-----

-

git has quite a wonderful tool named git-bisect. In short, it helps track

down what particular commit introduced a bug. Let's say your builds fail

for some reason, and the build-scripts send out the build-log to the

developer. The script can then continue to check the repo by running git

bisect on it and finding the commit that introduced the build-error, and

email that too to the developer. In short, when you check things in at

5 o'clock that doesn't build, you don't have to sit there and wrestle with

it. You can go home, have dinner, tuck the kids into bed, and then open

your mailbox and have an email with the exact commit that introduced the

regression.
Now, if you can also convince your developers to make small and isolated

commits, and your build-system is such that it doesn't rebuild *everything*,

but has proper dependency tracking and suchlike (a properly written Makefile

for example), the developer will get pointed to a commit that affects perhaps

10-20 lines of code within a reasonable time, and it should be so trivial to
I'm not sure what you mean by that. You can tell git to automatically fetch

any new branches (that's the default, I think), but you'll ofcourse have to

switch to using git-pull instead of cvs co (or whatever you're using now),

unless you use git-cvsserver. AFAIK, git-cvsserver mimics a cvs server well

enough that it accepts all commands and the two are interchangeable (assuming
Yes. It works incrementally, but since cvs commits aren't atomic, you

have to wait 10 minutes after the cvs commit *starts* to be able to

use cvsimport to move it over to git.
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

Hi,
Where did you read that?  AFAIK git-cvsserver is one option.  The other is

cvsexportcommit.  The former is more appropriate if you want to switch the

developers over to git, and want to provide a smooth path for the devs (or

cannot convert a few hardcore CVS "fans").
The latter is appropriate if you cannot control the server side, or are 
I don't know how cvsweb copes with git-cvsserver, but I guess that there 
My suggestion: if you're fine with CVS, stick with it.  Really.  I am not

here to teach the whole world about the advantages of git, so by all

means, if you yourself do not find any advantage to using git, don't use

it.  Stick with what works for you.
Ciao,

Dscho
-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Don't recall exactly, I thought it was a page like the one showing
I've got root access on the CVS server and want to switch to git without

disturbing the environment more than is necessary to make the switch.

I think developers will want to us git and git-cvsserver looks like
We are definitely not fine with CVS, the branch merging isn't

comfortable. I'm just wondering about maintaining the existing

CVS browsers and the build scripts if it's not a big deal. I'll

try the git-cvsserver path. If anyone has any war stories to share

on the path this would be an ideal time to share them.
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHF/jPJICwm/rv3hoRAkXgAJ9pa/DHxka926i3FHqYTsxCb5kzcQCeKiSk

j/Paxc6tJemOPK0TV8MhFGs=

=ut2Q

-----END PGP SIGNATURE-----

-

As for web browsing the history, our project was quickly convinced

gitweb is a lot better than cvsweb.  We are starting to get use to

basic git.  One developer works on CVS.  This is a bit handicapped,

but workable after a few patches to git-shell and git-cvsserver.
In another project I use git-cvsserver to do the Windows builds.

All development except for minor typos and compatibility things is

done on linux and cvs <-> git works just fine for that model.
	--- Jan
-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Could you tell me a bit more about those patches and the need for using

git-shell (haven't even messed with that yet).
Think I can set things up so the CVS updates, checkouts, and the

like that are being used on our build machines can remain untouched

and have the git-cvsserver exactly acting like the current CVS server.

It would be nice if branches and tags work without touching all of the

build machines and their scripts.
I don't think we need to have any developers continuing to use CVS;

but I may be wrong. I think I read that there's a limitation to being

on the main branch and unfortunately most of out tags are on a release

branch.
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGHG9JICwm/rv3hoRApQIAJ0Ys6QwxnBAu9tNWrGLU9svwtYXZwCeIFlq

Yr8snPT8TW/nBxFygFr95Ik=

=MtJS

-----END PGP SIGNATURE-----

-

One patch concerned handling "cvs update -p", which was accepted and I

guess will end up in the stable version someday.  One concerned handling

"cvs diff -c", which I never submitted.  I first tried a more general

approach to get diff option processing complete, but I had to backtrack

on that.  Now I have a quite simple hack, but more complete coverage of

diff option processing requires a bit more perl knowledge than I have.
I submitted a patch for shell.c to make it call "git cvsserver server"

if a commandline "cvs server" was passed to it, so you can do CVS+SSH

compatible to normal CVS.  I got so many comments I decided to keep it
No, you can checkout any GIT branch as it it were a CVS module.
	--- Jan
-

Hi,
I was responsible for a medium long running CVS repository, and I wanted

to switch to git.  For a long time, I just ran tests and tried to flesh

out things, and eventually went for it.
A few of the patches to git-cvsserver from me were direct results of

problems we ran to.  But mind you, that was almost over a year ago.
In the meantime, many of my developers switched.  Some because it was

easier than waiting for me to fix the bugs with the cvs server.
Some because they saw me working with git.
I still do not know why the third group switched.
Now I have exactly one dev left, who refuses to use anything else than

cvs.  Fine with me.  I can live with other people using inferiour programs

than myself.
I even patched cvsserver not to print the "committed using git-cvsserver"

message locally.
But then, I was never a cvs "power" user.  Only a git power user.
Ciao,

Dscho
-

Depending on the environment and the willingness of people to change to

git, it might be worth moving slowly and keeping the backend as CVS at

first.  I.e., keep the "official" repository as CVS, and let some devs

start moving to access through git-cvsimport and git-cvsexportcommit

(and maybe even provide an official git repo which is backed by the CVS

repo, so that all of the import/export happens in one place).  That will

give them time to get used to git, give those who are resistant to the

change their original interface, and if anything goes wrong, you can

always fall back to the "old" way.
And then when everything seems to be going well, swap it. Make git the

official repo, but provide a "legacy" CVS access for the die-hards

(using git-cvsserver).
And then eventually just shut off CVS access entirely (when everyone is

happier using git).
Of course none of that is necessary, but one of the nice things about

git is how it can integrate with existing setups, so you can really ease

into a transition without investing a lot of resources.
-Peff

-

kompare is pretty fast. Obviously not as fast as less.
"git diff HEAD HEAD~1000|kompare -" takes less than two seconds (hot cache)

on my machine. With small diffs it is almost instantaneous.
-- robin

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Marco Costalba wrote:
Great, I installed Qgit version 1.5.3 a while ago, I didn't

notice these advantages over gitq.
Yea, I just noticed, if I pull down External Diff in the files
It's not quite a intuitive/familiar as with bitkeeper. I suspect I just

need some practice. I selected a huge list if files that we use to

filter the release with and double clicked on the file I thought showing

to focus on that file. The I pulled down External Diff and it took for

ever; like it's confused.
Often we/I want to see the rev history for a particular file.
I'll get the latest and greatest. Thinks. Often the problem is

having the current version of Qt3. My workstation is Mandrake

1005 Limited Edition (X11 Xinerama works on this release).

Looks like I have Qt3 on my workstation. Would it be worthwhile
What new features are in 2.0 over 1.5.7?
Thanks Marco,
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFFS0JICwm/rv3hoRAlFIAJsEbp22Fs1fGVlt+RIXOOjJ3ZiqIQCeIQ1/

nG/JJUfuNNyoIL2MUJppId4=

=JQWE

-----END PGP SIGNATURE-----

-

You shoudl select only _one_ additional revision.
The currenlty selected revision is the base + select another one

(only) with CTRL + *RIGHT* click (the file list change background
Select the file from the file list (right bottom pane) or from the

tree view (use key 't' to toggle treev view) double click on it or use
See above.
I know I'm going to tell you a very _unpopular_ thing, but, in case

you have 5 minutes of spare time (yes, it doesn't take longer), open

qgit then please press a nice key called 'F1', a nice handbook will

appear...
I really suggest to look at it. To keep UI 'clean' a lot of features

are not immediatly visible, so reading the handbook (at least the

chapter's titiles) would give you a better idea of what qgit could do
Yes it is. There are a lot of new featrures, is almost as stable as

the previous and if you are interested in file history (annotations)

in qgit-2.0 this feature has been greatly speeded up.
Have fun

Marco

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
't' worked fine but still can see how to diff do of the list of

changes for a file. Viewing diffs of files based on change sets

worked fine but I think with BitKeeper I found it helpful to be

able to do a full 'kompare' type diff the file only; often I'm

not interested in which change set it went into.
Something for a future version or am I lucky and you have
Good Idea, thought it's brought up a few questions:
	1. When I do the <control-minis> to Decrease the font size

	   I can't undo it with the <control-plus>. Also <control-plus>

	   doesn't seem to do anything.
	2. When displaying the "Lane info" why can't I see the
I'll read it a few more times. I seem to sometimes get into a state

where I'm locked onto the current change set and can't get back to
Do you know if it's a lot of work to install Qt4?
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFZv5JICwm/rv3hoRAky6AJ47DFL/pWa8CCHv0ezw0wdkLLmbIQCeJqZN

cNHuMINv2/7fmnwczWcowhs=

=VSZN

-----END PGP SIGNATURE-----

-

Well, open tree view ('t'), select the file you are interested of,

then click the magic wand button on the tool bar, now revisions you

see are filtered by that file, if you browse the revisions the

patch/diff you see will always point to your file (also if you can see
Thanks for the reports, I will investigate as soon as I have a bit of
Please, could you be so kind to better explain me the above point.
With Mandriva you are just at an uprmi away.
Try something like
urpmi libqt4-devel
It worked for me ;-)
Marco

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
I take it the "magic wand button" is the check mark on the upper right

that says "Pin View (Alt-V)".  When I pin the view the view of the file

in Qgit locks to the selected file but the External diff seems to stay

the same. The External diff appears to show my last change to the file;

changing the change-set selection doesn't seem to change anything with
I'm not sure how I get into this state either, I'll try to recall
    /nethome/piet$ su

    /nethome/piet$ /usr/sbin/urpmi libqt4-devel

                   no package named libqt4-devel

    /nethome/piet$
I'm running 2005 Limited Edition; I wonder if QT4 even existed then.

Think it's worth messing with QT4 just to upgrade to you latest version?

Some of these graphics libs can be bear to install from src.
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFoLhJICwm/rv3hoRAt73AJ9kWv8EhuaAH/69HqG0+FZOAD8LlgCdH6uU

2PJDFOuZENrKJBA66MOdANc=

=yd6t

-----END PGP SIGNATURE-----

-

The only thing I really, really, really don't like about qgit4 is the

fact that it fudges up the commit-message. I've been trying for two

days to get rid of the HTML output, but I just can't get it done

without the signed-off-by email being enclosed in <> tags.
Marco, is there any chance you could make the old commit-message view

an option? Especially, the subject line should really, really be at the

bottom, with the rest of the message-text (although I liked the other

view without the colored box a lot more). The little arrows in the

commit window are also fairly annoying, as one quite quickly understands

that up-/down-arrows work much better for that sort of stuff anyway.
I'm at my wits end wrt c++ and qt, and can't for the life of me think of

how to make it an option :(
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

You mean when you commit some changes or when you brows the revisions?
If it is the highlighted title that annoy you I can try to remove the
Little arrows should already be removable from settings->browse->'Show

smart labels' , you can also add lateral tabs with

settings->browse->'Show tabbed revisions' if you like.
Marco

-

That does annoy me indeed, but the primary annoyance is the fact that

the subject is no longer listed with the rest of the commit message, but
Sweet. I'll have to look into it. Thanks for your gentle instruction, and

a great product :)
--

Andreas Ericsson                   andreas.ericsson@op5.se

OP5 AB                             www.op5.se

Tel: +46 8-230225                  Fax: +46 8-230231

-

kompare can read the unified diffs.  If you add enough context, the result

is no different than the full files.
David

-

Ahh, good pointer. I had to google for it to find that it's part of the

kdesdk package, which I hadn't installed. But a simple "yum install

kdesdk" worked fine.
Much better than my stupid script ;)
		Linus

-

What's difftool?  What's so great about it?
Forgive my ignorance but it has been many years since I last used

BitKeeper and even when I did use it I didn't get into many of the

features it offered.  Its entirely possible I never learned about

difftool.
I've never found that I cannot get the information I need out of Git

when I need it.  Actually I've found it to be the easiest VCS to get

data out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.

Of course I also know Git better than I know those tools...
--

Shawn.

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
It's a side by side graphical diff. So instead of showing the difference

like diff does it takes the output from diff and shows the originals

with the diffs highlighted.
tkdiff is a good example that's easy to down load and see. So

just imagine allowing git-gui to run tkdiff of revisions you select
Try downloading tkdiff. There also a X implementation,
Try tkdiff and then tell me you don't find it easier to read that

the straight output from diff.
- -piet
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFAi4JICwm/rv3hoRAluCAJ9jFrA9G8aKQi1rtM2CSiNnmhlo4wCeJjk7

LONAM+lzvin021HAhQ8jKoE=

=QsE/

-----END PGP SIGNATURE-----

-

Both.  Most of the time, I find the diff output easier to read.  Only when

a change modifies a whole bunch of lines sprinkled around do I find the

side-by-side format easier.  Even then, it is only marginal.
However, asking for a side-by-side diff viewer is probably the most common

request I've gotten from people I work with starting to use git.
David

-