* Re: git-p4import.py robustness changes
From: Shawn O. Pearce @ 2007-06-04 6:18 UTC (permalink / raw)
To: Dana How; +Cc: Scott Lamb, Simon Hausmann, Junio C Hamano, git
In-Reply-To: <56b7f5510706032309w4aee791dnd3bf5d46974bdaba@mail.gmail.com>
Dana How <danahow@gmail.com> wrote:
> On 6/3/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >I think writing data to fast-import is much easier than running
> >the raw Git commands, especially when you are talking about an
> >import engine where you need to set all of the special environment
> >variables for git-commit-tree or git-tag to do its job properly.
> >Its a good tool that simply doesn't get enough use, partly because
> >nobody is using it...
>
> Well, perhaps they use it *once*, in that they write a wrapper script for
> it and then forget about it. At least that's what I did. And the _only_
> annoyance was the trailing NL requirement on the delimited "data" statement,
> so you don't get much noise/complaints when people use it.
True. I did try to make fast-import take a simple enough format
that you could write throwaway code against it, run it, and never
look back...
The trailing NL after data was because of cvs2svn. The SVN dump
file format apparently does something like this, and the version
of cvs2svn that Jon Smirl was working on output that trailing NL.
Accepting it in fast-import was easier than fixing cvs2svn to not
create it.
I'll admit the error handling in fast-import could probably
be easier, and that NL after data probably could be optional.
I don't think the input stream parser needs it to understand what
is going on. Its just sheer laziness on my part that the code
requires it there.
--
Shawn.
^ permalink raw reply
* Re: [tig PATCH] Fix integer type mismatch on 64-bit systems
From: Jonas Fonseca @ 2007-06-04 6:47 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20070603211206.GA16445@midwinter.com>
On 6/3/07, Steven Grimm <koreth@midwinter.com> wrote:
> fprintf wants an int parameter for the field width of a "%.*s" expression, but
> the code was passing a size_t instead. This potentially broke systems where
> sizeof(size_t) != sizeof(int). And even on systems where it did't break,
> it still caused a compiler warning.
Thanks, I also fixed another such occurrence.
BTW, in good git spirit you are encouraged to sign off your patches. :)
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Johannes Sixt @ 2007-06-04 7:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706030129110.4046@racer.site>
Johannes Schindelin wrote:
>
> This script is derived from Pasky's cg-admin-rewritehist.
>
> In fact, it _is_ the same script, minimally adapted to work without cogito.
> It _should_ be able to perform the same tasks, even if only relying on
> core-git programs.
>
> All the work is Pasky's, just the adaption is mine.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Hopefully-signed-off-by: Petr "cogito master" Baudis <pasky@suse.cz>
If you hadn't done that, I'd done it sooner or later. Thanks!
> + -r)
> + unchanged="$(get_parents "$OPTARG") $unchanged"
> + ;;
> + -k)
> + unchanged="$(git-rev-parse "$OPTARG"^{commit}) $unchanged"
> + ;;
These two (-r and -k) together with...
> +# seed with identity mappings for the parents where we start off
> +for commit in $unchanged; do
> + echo $commit > ../map/$commit
> +done
... this and ...
> + if [ -r "../map/$parent" ]; then
> + for reparent in $(cat "../map/$parent"); do
> + parentstr="$parentstr -p $reparent"
> + done
> + else
> + die "assertion failed: parent $parent for commit $commit not found in rewritten ones"
... this, means that any simple command like
git filter-branch -k orgin/master origin/next new-next
of your git.git clone will fail with the "assertion failed". (I haven't
tried your script, yet, but cg-admin-rewritehist fails.)
I propose that you just get rid of the "seed" stance and don't fail if a
commit cannot be mapped - just use it unchanged (don't forget to adjust
the map() function, too). Then you can get rid of -r and use -k to
specify everything you want under "--not" in the rev-list.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Use git-tag in git-cvsimport
From: Martin Waitz @ 2007-06-04 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Elvis Pranskevichus, git
In-Reply-To: <7vabvgmvuo.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
hoi :)
On Sun, Jun 03, 2007 at 05:01:03PM -0700, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
> > but lightweight tags are not fetched by default.
>
> Are you sure about that?
not any more now that you questioned it ;-)
But at least there is a hook script which refuses to receive
un-annotated tags and I always considered those tags to be temporary
tags in the local repository.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Scott Lamb @ 2007-06-04 7:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Simon Hausmann, Junio C Hamano, git
In-Reply-To: <20070604055433.GD4507@spearce.org>
On Jun 3, 2007, at 10:54 PM, Shawn O. Pearce wrote:
> I think writing data to fast-import is much easier than running
> the raw Git commands, especially when you are talking about an
> import engine where you need to set all of the special environment
> variables for git-commit-tree or git-tag to do its job properly.
> Its a good tool that simply doesn't get enough use, partly because
> nobody is using it...
Yeah, I'm sold. I read git-p4 more thoroughly and tried it out...it's
pretty nice. The P4Sync command has a simpler, more trustworthy flow
than git-p4import.py.
On the Perforce side, I particularly like the use of "p4 print" to
grab the files instead of "p4 sync". It avoids playing weird games
with the client - I think nothing good can come of git-p4import.py's
"p4 sync -k" and symlinks to map multiple branches into the same
directory, which is not the Perforce way. Makes me nervous that
what's submitted to git won't be the same as what's in the Perforce
depot.
I would have thought launching a "p4 print" on each file would be
horribly slow with the network latency of each request, but...well,
apparently not.
Maybe I'll work up git-p4 patches for subcommand error handling, like
my git-p4import.py ones. And fix some style - seriously, who puts
semicolons at the end of Python commands? *grumble*
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: [PATCH] Support environment variables in config file
From: Martin Waitz @ 2007-06-04 7:27 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070604053443.GA15148@moooo.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
hoi :)
thanks for the review!
Do you think the approach is ok?
Can you see other examples where we may need $VAR support?
Or would everybody be happy with support for ~/ in filenames?
On Mon, Jun 04, 2007 at 07:34:43AM +0200, Matthias Lederhofer wrote:
> Martin Waitz <tali@admingilde.org> wrote:
> > Environment variables (e.g. $HOME) can be helpful for the GIT configuration.
> > With this change you can use them with the normal shell "$" syntax.
> > If you want to insert a plain "$" in a variable, it can be escaped as \$
> > or put inside quotes (").
>
> Perhaps we should also allow variable interpolation in double quoted
> strings as this is quite common in various languages.
I thought about that too. I guess I first will have to do a patch
which adds single quote (') support.
> We could have a short example here how to concatenate a variable and a
> string without a space in between. I came up with '$FOO""bar' which
> is not that obvious imo.
yes, shell-like ${FOO} would be nicer but I don't know if it is that
important. Perhaps your example $FOO"bar".
> You should allow at least underscores in environment variables too.
right
> If you use the HOME environment variable without setting it yourself
> you should place quotes around the $(..) in case there is a space in
> $HOME:
stupid error, yes.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] Refactor git tag objects; make "tag" header optional; introduce new optional "keywords" header
From: Johan Herland @ 2007-06-04 7:30 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070604060812.GC15148@moooo.ath.cx>
On Monday 04 June 2007, Matthias Lederhofer wrote:
> Johan Herland <johan@herland.net> wrote:
> > 1. Make the "tag" header optional. The "tag" header contains the tag
name,
> > which is optional for 'notes'. The new semantics for the "tag" header
> > are as follows: The tag header _must_ be given for signed tags (this
> > is already enforced by git-tag.sh). When the tag header is not given,
> > its value defaults to the empty string.
>
> Why must signed tags have a tag header? Will notes optionally have a
> tag header?
The purpose of signing a tag is to cryptographically verify the thing
pointed at by the tag. But you also want to protect the tag itself. In
order to make it harder for someone to rename a signed tag (thereby opening
the door to replacing it with a different - possibly signed - malicious
tag), you want to include the tag name in the signed data. This allows us
to verify that the tag ref (as stored in '.git/refs') is identical to the
tag name stored inside the signed object.
Yes, 'notes' will optionally have a "tag" header. When I originally designed
notes, I didn't think anybody would want to name their notes, but Linus
requested it, and there's no technical argument against it. Note that if
you name your note, and put a ref to it (under '.git/refs'), there's
technically no distinction between a tag object and a note object, except
what you choose to put in the "keywords" header, of course.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Improved git-gui blame viewer
From: Martin Waitz @ 2007-06-04 7:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthijs Melchior, git
In-Reply-To: <20070604060720.GF4507@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
hoi :)
On Mon, Jun 04, 2007 at 02:07:20AM -0400, Shawn O. Pearce wrote:
> > When clicking on a light gray line to become a green line, then
> > adjacent areas are not correctly colored. A few adjacent entries
> > become all same gray... [Look around git-gui.sh:340]
>
> This (I think) is because of the way the color selections are
> being done. git-gui is being stupid and just alternating colors to
> commits as they come in from `git blame --incremental`. The thing
> about the incremental blame is I can receive data for any part of
> the file at any time. So in general what happens is I get data for
> one part of the file, give it color A, then data for another part,
> give it color B, and then get data for part that is right next to the
> first A and assign it A again. So you see chunks where there is no
> alternating...
If you use three colors you can always select one which is different
to the hunk above and below. But I don't know if that would be
visually appealing...
Another nice thing would be a smooth gradient for each hunk.
Then we could use the same colors for every hunk, but the top of each
hunk would be a little bit lighter/darker than the bottom so that
it is easy to see the border. Is that doable in Tk?
Perhaps a simple small line between hunks is enough, too?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Junio C Hamano @ 2007-06-04 7:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Shawn O. Pearce
In-Reply-To: <20070603130745.GC2495@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> by default. V=1 works as usual.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Updated. BTW, where does "no $(call) in Makefile" came from?
> It could simplify the thing a lot
Probably, but first let's make it "work right" while not
introducing new stuff.
> diff --git a/Makefile b/Makefile
> index cac0a4a..6409b9c 100644
> --- a/Makefile
> +++ b/Makefile
> ...
> @@ -972,34 +975,53 @@ check: common-cmds.h
>
> ### Installation rules
>
> +ifeq ($(QUIET),@)
> +INST_0 = arg=
> +INST_1 = &&echo " INSTALL $$arg"&&$(INSTALL) "$$arg" # space
> +BSETUP_0 = arg=
> +BSETUP_1 = &&echo " SETUP BUILTIN $$arg"&& \
> + rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" && \
> + ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$(X)' \
> + '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" # space
> +else
> +INST_0 = $(INSTALL) # space to separate "install" and its first arg
> +INST_1 =
> +BSETUP_0 = arg=
> +BSETUP_1 = &&rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" && \
> + ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$(X)' \
> + '$(DESTDIR_SQ)$(gitexecdir_SQ)/'"$$arg" # space
> +endif
> +
> install: all
> $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(bindir_SQ)'
> $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
I found Shawn's "DEST = $this_directory" quite decent. Forgot
to port it?
^ permalink raw reply
* Re: [PATCH 3/6] git-fsck: Do thorough verification of tag objects.
From: Johan Herland @ 2007-06-04 7:51 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070604055655.GB15148@moooo.ath.cx>
Teach git-fsck to do the same kind of verification on tag objects that is
already done by git-mktag.
Signed-off-by: Johan Herland <johan@herland.net>
---
Matthias Lederhofer <matled@gmx.net> wrote:
> The objerror() function prints the sha1 and object type, I think this
> one should be used instead of error() here.
Of course, you're right. Like this, I hope:
builtin-fsck.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index cbbcaf0..71a5fd5 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -344,6 +344,20 @@ static int fsck_commit(struct commit *commit)
static int fsck_tag(struct tag *tag)
{
struct object *tagged = tag->tagged;
+ enum object_type type;
+ unsigned long size;
+ char *data = (char *) read_sha1_file(tag->object.sha1, &type, &size);
+ if (!data)
+ return objerror(&tag->object, "could not read tag");
+ if (type != OBJ_TAG) {
+ free(data);
+ return objerror(&tag->object, "not a tag (internal error)");
+ }
+ if (parse_and_verify_tag_buffer(0, data, size, 1)) { /* thoroughly verify tag object */
+ free(data);
+ return objerror(&tag->object, "failed thorough tag object verification");
+ }
+ free(data);
if (!tagged) {
return objerror(&tag->object, "could not load tagged object");
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Add git-filter-branch
From: Johannes Sixt @ 2007-06-04 7:59 UTC (permalink / raw)
To: git
In-Reply-To: <4663BCDA.F1BADDD8@eudaptics.com>
Johannes Sixt wrote:
> ... this, means that any simple command like
>
> git filter-branch -k orgin/master origin/next new-next
Make this:
git filter-branch -k orgin/master -s origin/next new-next
-- Hannes
^ permalink raw reply
* Re: [PATCH] Show html help with git-help --html
From: Junio C Hamano @ 2007-06-04 8:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20070602015341.GA26520@localhost.myhome.westell.com>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 3d8f03d..2ec8545 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -261,6 +261,18 @@ core.excludeFile::
> ...
> +core.htmlprogram::
> + Specify the program used to open html help files when 'git-help'
> + is called with option --html or core.help is other than 'man'.
> + By default, xdg-open will be used.
Is the program's calling convention something that needs to be
customizable for this to be useful?
> diff --git a/Makefile b/Makefile
> index cac0a4a..43e0d15 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -145,6 +145,7 @@ prefix = $(HOME)
> bindir = $(prefix)/bin
> gitexecdir = $(bindir)
> sharedir = $(prefix)/share/
> +htmldir = $(sharedir)/html/
> template_dir = $(sharedir)/git-core/templates/
> ifeq ($(prefix),/usr)
> sysconfdir = /etc
Is it customary to have HTMLized documentation material for
different packages all together in a single .../share/html/
directory, like manpages are placed in share/man/man1/
directory? I somehow had an impression that a layout to have
html directory per package (i.e. share/doc/$pkg/html/) was more
common. I dunno.
> diff --git a/help.c b/help.c
> index 6a9af4d..e3e705b 100644
> --- a/help.c
> +++ b/help.c
> @@ -183,6 +187,36 @@ static void show_man_page(const char *git_cmd)
> execlp("man", "man", page, NULL);
> }
>
> +static void show_html_page(const char *git_cmd)
> +{
> + const char *html_dir;
> + int i,len,ret;
> + char *p;
> +
> + html_dir = HTML_DIR;
> + if (!html_help_program)
> + html_help_program = "xdg-open";
> +
> + /* html_help_program space html_dir git- git_cmd .html */
> + len = strlen(html_help_program) + 1 + strlen(html_dir) + 4 + strlen(git_cmd) + 5;
> + p = xmalloc(len + 1);
> +
> + strcpy(p, html_help_program);
> + strcat(p," ");
> + strcat(p,html_dir);
> + if (prefixcmp(git_cmd, "git"))
> + strcat(p,"git-");
> + strcat(p,git_cmd);
> + strcat(p,".html");
> +
> + ret = system(p);
This is sloppy in the presense of potentially unsafe characters...
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Andy Parkins @ 2007-06-04 8:21 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <e5bfff550706031339v5ffda0a6u6f520f0c7b49f442@mail.gmail.com>
On Sunday 2007 June 03, Marco Costalba wrote:
> Care has been taken to allow the wheel browsing experience to be as
> natural as possible, in particular a way to avoid to switch when user
> just wants to scroll has been implemented. Also, getting a responsive
> scroll and switch command avoiding false positives was not immediate.
I'm really sorry to say it Marco, but it's really disturbing. You've
obviously made great efforts to make it useable, but it just isn't. The
scroll wheel behaviour being inconsistent is just annoying. Sometimes
scrolling works, sometimes it doesn't, sometimes it switches content,
sometimes it doesn't. It's obviously based on timeouts for the different
functions, but that just means that I have no idea what a particular
operation will do at any given time.
I'm not sure I like the labels with arrows either; and the fonts changing size
and visibility is inconsistent and discomfiting.
On the plus side - I do like the idea of being able to perform these
operations; jumping from revision to revision, or from log to patch is nice.
However, I think it is unwise to invent a new graphical metaphor for an
operation that already exists - the tabbed widget. Similarly, the up and
down are obvious candidates for toolbar buttons - an already established
visual.
So - I think that the non-standard methods should be dropped (sorry); and be
replaced with tabs for the patch/log switch and toolbar buttons for the
up/down. Also, the scroll-to-switch, while an interesting idea, gives
unpredictable behaviour and so is uncomfortable to use.
Sorry for being so negative; it's a shame after your obvious hard work.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Improved git-gui blame viewer
From: Shawn O. Pearce @ 2007-06-04 8:21 UTC (permalink / raw)
To: Martin Waitz; +Cc: Matthijs Melchior, git
In-Reply-To: <20070604073827.GF16637@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
>
> On Mon, Jun 04, 2007 at 02:07:20AM -0400, Shawn O. Pearce wrote:
> > > When clicking on a light gray line to become a green line, then
> > > adjacent areas are not correctly colored. A few adjacent entries
> > > become all same gray... [Look around git-gui.sh:340]
>
> If you use three colors you can always select one which is different
> to the hunk above and below. But I don't know if that would be
> visually appealing...
That's actually not a bad idea. But to make that work I have to
do the coloring by line chunks, not commits. Given how bad the
current by-commit coloring is, the 3 coloring by line chunks is
probably the best bet. It would resemble what gitweb does, but
we'd be using 3 colors in git-gui vs. the 2 in gitweb. We could
do worse.
> Another nice thing would be a smooth gradient for each hunk.
> Then we could use the same colors for every hunk, but the top of each
> hunk would be a little bit lighter/darker than the bottom so that
> it is easy to see the border. Is that doable in Tk?
I think so, but its ugly. The viewer is actually 4 text widgets
crammed next to each other. I can set the background color of a
line by giving it a tag, so to do a gradient I have to assign a
different background color to each line by giving each line its
own tag (ick). Worse, in a 3 line chunk I can only do 3 colors.
That fails your "smooth" concept. ;-)
> Perhaps a simple small line between hunks is enough, too?
That would be messy. I can certainly cause a few pixels of spacing
to show up between chunks, but I'm reading the data "live" from the
blame engine and putting it on screen. Adding space betwen chunks
as I get it will cause the data to "reflow" while you are trying to
read it. I can probably account for it with the scrollbar and adjust
it accordingly, but at some point you will wind up seeing the text
in the viewer pane moving around and expanding as the padding gets
tossed in.
BTW, I just got the jump-to-original line and restore-view-on-back
features that Matthijs was asking about working properly. Apparently
a call to Tk's "update" (basically just let Tk pump its event loop)
is needed after I've finished reading the file content, but before I
adjust the view. Its in my pu branch now (gitgui-0.7.2-58-gf9e96fd).
--
Shawn.
^ permalink raw reply
* StGIT munged path on refresh
From: Andy Green @ 2007-06-04 8:24 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Hi folks -
I have been using quilt with some success and now I am trying to migrate
to stgit. I can get started okay with stg init and stg new "mypatch",
stg refresh then picks up modifications without having to be told about
the changed files, very nice.
However after I have modified several files in the tree, stg refresh
breaks without my having changed anything in the meantime to do with
stgit. The problem looks like this:
$ stg refresh
Checking for changes in the working directory... done
Refreshing patch "mISDN-remove-unused-test-from-bitops.patch"...error:
drivers/isdn/hardware/mISDN/drivers/isdn/hardware/mISDN/appl.c: does not
exist and --remove not passed
fatal: Unable to process file
drivers/isdn/hardware/mISDN/drivers/isdn/hardware/mISDN/appl.c
stg refresh: Failed git-update-index
$ pwd
/projects/octotux/packages/mISDN-1.2.0/drivers/isdn/hardware/mISDN
$ ls appl.c
appl.c
The tree starts at /projects/octotux/packages/mISDN-1.2.0, ie, there is
a .git/ in there. Notice that in the diagnostic, the path after the
start of the tree is repeated twice :-( but I did not run any stg or git
commands between a successful stg refresh and the first broken one.
In case it is important, I am working on a branch called "portability".
This is with
# rpm -q git-core
git-core-1.5.0.6-1.fc7
# rpm -q stgit
stgit-0.12.1-2.fc7
-Andy
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Marius Storm-Olsen @ 2007-06-04 8:41 UTC (permalink / raw)
To: Scott Lamb; +Cc: Simon Hausmann, Junio C Hamano, git
In-Reply-To: <839AEF71-ED29-4A79-BE97-C79EAFEDC466@slamb.org>
[-- Attachment #1: Type: text/plain, Size: 811 bytes --]
> git-p4import.py should work fine on Windows, too - the binary mode on
> the pipe should be all handled by "subprocess", and git-p4's
> data.replace("\r\n", "\n") is not necessary if you use "LineEnd:
> unix" or "share" in the Perforce client specification.
The problem is that you cannot set the LineEnd when using the 'p4
print' command, since it doesn't use the client spec; so Perforce the
uses the platform default when printing the file.
> git-p4 seems to use "git fast-import". I guess the big performance
> improvement there is removing the ls-files operation? So we're
> talking about a 0-10% speedup, right? Plus some fork()/exec()
> overhead.
With git-p4 the performance bottleneck is from what we can see the
Perforce server, on non-Windows machines.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Support environment variables in config file
From: Matthias Lederhofer @ 2007-06-04 8:44 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20070604072707.GE16637@admingilde.org>
Martin Waitz <tali@admingilde.org> wrote:
> Do you think the approach is ok?
Looks fine from the reading part. Up to now
$ git config "$key" "$value" &&
[ "$value" = "$(git config "$key")" ] &&
echo true
will echo true for all values (at least from the things I tried with
", \ and \n). When interpreting $VAR this changes. I dunno if there
are any programs out there that rely on the fact that the value you
get out of the config is exactly the same as you have put in.
> Can you see other examples where we may need $VAR support?
> Or would everybody be happy with support for ~/ in filenames?
In my config I don't even use the path to my home directory anywhere
and spontaneously I can't think of any config option for which I'd use
an environment variable as value.
^ permalink raw reply
* Re: Improved git-gui blame viewer
From: Martin Waitz @ 2007-06-04 8:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthijs Melchior, git
In-Reply-To: <20070604082156.GI4507@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
hoi :)
On Mon, Jun 04, 2007 at 04:21:56AM -0400, Shawn O. Pearce wrote:
> I think so, but its ugly. The viewer is actually 4 text widgets
> crammed next to each other. I can set the background color of a
> line by giving it a tag, so to do a gradient I have to assign a
> different background color to each line by giving each line its
> own tag (ick). Worse, in a 3 line chunk I can only do 3 colors.
> That fails your "smooth" concept. ;-)
yeah, if each line has a solid background that does not work :-(
> > Perhaps a simple small line between hunks is enough, too?
>
> That would be messy. I can certainly cause a few pixels of spacing
> to show up between chunks, but I'm reading the data "live" from the
> blame engine and putting it on screen. Adding space betwen chunks
> as I get it will cause the data to "reflow" while you are trying to
> read it. I can probably account for it with the scrollbar and adjust
> it accordingly, but at some point you will wind up seeing the text
> in the viewer pane moving around and expanding as the padding gets
> tossed in.
Well, it would work if you could just draw a one-pixel line (in some
subtle gray) inbetween lines, without changing the layout.
> BTW, I just got the jump-to-original line and restore-view-on-back
> features that Matthijs was asking about working properly. Apparently
> a call to Tk's "update" (basically just let Tk pump its event loop)
> is needed after I've finished reading the file content, but before I
> adjust the view. Its in my pu branch now (gitgui-0.7.2-58-gf9e96fd).
nice :-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] cvsimport: add support for new style remote layout
From: Andy Whitcroft @ 2007-06-04 8:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvee4n1et.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
>> cvsimport creates any branches found in the remote CVS repository
>> in the refs/heads namespace. This makes sense for a repository
>> conversion. When using git as a sane interface to a remote CVS
>> repository, that repository may well remain as the 'master'
>> respository. In this model it makes sense to import the CVS
>> repository into the refs/remotes namespace.
>>
>> Add a new option '-r <remote>' to set the remote name for
>> this import. When this option is specified branches are named
>> refs/remotes/<remote>/branch, with HEAD named as master matching
>> git-clone separate remotes layout. Without branches are placed
>> ion refs/heads, with HEAD named origin as before.
>
> Sounds good. Docs?
Heh, yep if its something wanted then it needs docs. Will drop a couple
of patches following this email. The first is the documentation
updates. The second adds a HEAD link matching git-clone behaviour, and
handily calling cvs HEAD remotes/<remote>/HEAD which seems appropriate.
-apw
^ permalink raw reply
* [PATCH 1/2] cvsimport: update documentation to include separate remotes option
From: Andy Whitcroft @ 2007-06-04 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <4663D42A.7090201@shadowen.org>
Document the cvsimport -r <remote> option which switches cvsimport
to using a separate remote for tracking branches.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index e0be856..4e5f1c6 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
- [<CVS_module>]
+ [-r <remote>] [<CVS_module>]
DESCRIPTION
@@ -25,10 +25,12 @@ Splitting the CVS log into patch sets is done by 'cvsps'.
At least version 2.1 is required.
You should *never* do any work of your own on the branches that are
-created by git-cvsimport. The initial import will create and populate a
+created by git-cvsimport. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
to work with; after that, you need to 'git merge' incremental imports, or
-any CVS branches, yourself.
+any CVS branches, yourself. It is advisable to specify a named remote via
+-r to separate and protect the incoming branches.
+
OPTIONS
-------
@@ -51,10 +53,19 @@ OPTIONS
The git repository to import to. If the directory doesn't
exist, it will be created. Default is the current directory.
+-r <remote>::
+ The git remote to import this CVS repository into.
+ Moves all CVS branches into remotes/<remote>/<branch>
+ akin to the git-clone --use-separate-remote option.
+
-o <branch-for-HEAD>::
- The 'HEAD' branch from CVS is imported to the 'origin' branch within
- the git repository, as 'HEAD' already has a special meaning for git.
- Use this option if you want to import into a different branch.
+ When no remote is specified (via -r) the 'HEAD' branch
+ from CVS is imported to the 'origin' branch within the git
+ repository, as 'HEAD' already has a special meaning for git.
+ When a remote is specified the 'HEAD' branch is named
+ remotes/<remote>/master mirroring git-clone behaviour.
+ Use this option if you want to import into a different
+ branch.
+
Use '-o master' for continuing an import that was initially done by
the old cvs2git tool.
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index f16ac3d..7837c7b 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -40,7 +40,7 @@ Usage: ${\basename $0} # fetch/update GIT from CVS
[-o branch-for-HEAD] [-h] [-v] [-d CVSROOT] [-A author-conv-file]
[-p opts-for-cvsps] [-P file] [-C GIT_repository] [-z fuzz] [-i] [-k]
[-u] [-s subst] [-a] [-m] [-M regex] [-S regex] [-L commitlimit]
- [CVS_module]
+ [-r remote] [CVS_module]
END
exit(1);
}
^ permalink raw reply related
* [PATCH 2/2] cvsimport: add <remote>/HEAD reference in separate remotes more
From: Andy Whitcroft @ 2007-06-04 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <4663D42A.7090201@shadowen.org>
When in separate remote mode (via -r <remote>) we can now use
the name HEAD for the CVS HEAD. In keeping with git-clone
remotes/<remote>/HEAD is creates as a symbolic ref to the user
specified name for the HEAD which defaults to master.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 7837c7b..598b9c8 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -1026,6 +1026,8 @@ if ($orig_branch) {
print "DONE; creating $orig_branch branch\n" if $opt_v;
system("git-update-ref", "refs/heads/master", "$remote/$opt_o")
unless -f "$git_dir/refs/heads/master";
+ system("git-symbolic-ref", "$remote/HEAD", "$remote/$opt_o")
+ if ($opt_r && $opt_o ne 'HEAD');
system('git-update-ref', 'HEAD', "$orig_branch");
unless ($opt_i) {
system('git checkout');
^ permalink raw reply related
* Re: [RFC] git integrated bugtracking
From: Rogan Dawes @ 2007-06-04 9:32 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, git
In-Reply-To: <20070603230702.GC16637@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Sun, Jun 03, 2007 at 10:16:32PM +0200, Pierre Habouzit wrote:
>> Well I went that way, but we loose the quite cool "if I branch my
>> repository I branch the bugs coming with them too"-feature. And I'd be
>> sad to give that up. But maybe it's an error to want to use git to
>> encode that relation.
>
> Just store the commit which introduced the bug (or where the bug
> was first found) and you will get that, too. You only have to check
> if this commit is reachable by a given branch to see if it is affected.
> When you fix the bug you store the commit id that fixed it and then
> you can check every branch if it points into bad..good.
>
> You can also do this for released versions.
> If you have the bug database inside the repository you can't report
> any bugs for a released version, because it is, well already released.
>
Ok, that seems reasonable.
Now, how do you store updates to a bug? i.e. followup questions and answers?
As suggested in another message, I think that the bug id would have to
be the hash of the initial report (incl whatever metadata is considered
interesting).
I think that the individual reports might be stored by their id, perhaps
via a fan out dir, like the .git/objects directory. Attachments can be
stored by their hash in a separate directory structure. Modifications to
a report would simply be appended to the original report. Simultaneous
modifications could be dealt with by merging the two files, probably
using a custom merge driver.
Obviously the format of a bug report and follow up message would need to
be quite strictly defined and adhered to, for the merge driver to be
able to do its work with the minimum/zero user interaction.
Closed bugs would be deleted from the filesystem, but would obviously be
available via the history.
Indexes or categories could be implemented by means of symlinks/symrefs
in a different set of "index directories". e.g.
/categories/drivers/deadbeef -> ../../bugs/de/adbeef
/assignedto/joe@example.org/deadbeef -> ../../bugs/de/adbeef
or similar. These might not be strictly necessary, since all that
information will be in the report anyway. Perhaps the indexes would be
stored simply as cached data, and rebuilt if out of date.
The porcelain would then take care of presenting the bugs to the user in
the preferred format, much like we have gitk, gitweb, qgit, tig, etc.
Does any of this make sense?
Rogan
^ permalink raw reply
* Re: StGIT munged path on refresh
From: Andy Green @ 2007-06-04 10:36 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <4663CC54.7090203@warmcat.com>
Andy Green wrote:
> I have been using quilt with some success and now I am trying to migrate
> to stgit. I can get started okay with stg init and stg new "mypatch",
Sorry for the noise -- I found this is a FAQ, you currently have to do
the refresh at the top of the tree, unlike in quilt.
-Andy
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Marco Costalba @ 2007-06-04 11:20 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200706040921.55861.andyparkins@gmail.com>
On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Sunday 2007 June 03, Marco Costalba wrote:
>
> > Care has been taken to allow the wheel browsing experience to be as
> > natural as possible, in particular a way to avoid to switch when user
> > just wants to scroll has been implemented. Also, getting a responsive
> > scroll and switch command avoiding false positives was not immediate.
>
> I'm really sorry to say it Marco, but it's really disturbing. You've
> obviously made great efforts to make it useable, but it just isn't. The
> scroll wheel behaviour being inconsistent is just annoying. Sometimes
> scrolling works, sometimes it doesn't, sometimes it switches content,
> sometimes it doesn't. It's obviously based on timeouts for the different
> functions, but that just means that I have no idea what a particular
> operation will do at any given time.
>
Thanks for your comment. I will try to do the following:
- Allow to remove this possibility by unchecking a proper flag in
settings dialog.
- Change the color of the arrows, as example highlighting, when the
switch behavior became active, i.e. at the top and bottom of scroll
bar. So the user will know what a scroll action will do.
> I'm not sure I like the labels with arrows either; and the fonts changing size
> and visibility is inconsistent and discomfiting.
>
Ok I can use same font for both labels, not a biggie. Regarding the
arrows, any other idea to tell to the user something will happen when
scrolling is welcomed.
> On the plus side - I do like the idea of being able to perform these
> operations; jumping from revision to revision, or from log to patch is nice.
> However, I think it is unwise to invent a new graphical metaphor for an
> operation that already exists - the tabbed widget.
The tabbed widget is here to stay. I do not plan to remove it. But the
tabbed widget is also slower then a well behaved scroll swicth or link
clicking.
> Similarly, the up and
> down are obvious candidates for toolbar buttons - an already established
> visual.
>
This could be added, but it seems not needed to me given that for the
suer is faster to click on the previous/next revision in the revision
list then reaching the toolbar.
> So - I think that the non-standard methods should be dropped (sorry); and be
> replaced with tabs for the patch/log switch and toolbar buttons for the
> up/down. Also, the scroll-to-switch, while an interesting idea, gives
> unpredictable behaviour and so is uncomfortable to use.
>
> Sorry for being so negative; it's a shame after your obvious hard work.
>
Thanks for your comments. They are much more valuable and useful then
a 'yes...it seems more or less nice'.
Thanks
Marco
P.S: Scrolling is not based on timeouts. The rule is: if user starts a
scroll action while not at the extremes of the content then only a
scroll will occur. If the user starts a scroll action from one extreme
of the view (top or bottom) and the scroll direction goes toward out
of the screen then a switch will occur.
^ permalink raw reply
* Git Vs. Svn for a project which *must* distribute binaries too.
From: Bryan Childs @ 2007-06-04 11:48 UTC (permalink / raw)
To: git
Hello git users / maintainers / fans,
My fellow projecteers and I watched a presentation given by Linus
Torvalds on the advantages of git given at a google questions session
sometime recently.
Our project, www.rockbox.org, an open source firmware replacement
project for digital audio players currently makes use of subversion
for it's source code management system, but Linus's eloquent (though
sometimes rather blunt) speech has made us question whether git is
perhaps a better solution for us.
On the whole, we like a lot of the features it offers but, we have a
couple of issues which we've discussed, and so far have failed to come
up with a decent resolution for them.
1) Due to the nature of our project, with multiple architectures
supported, we strive to provide a binary build of our software with
every commit to the subversion repository. This is so that we can
provide a working firmware for the majority of our users that don't
have the necessary know-how for cross-compiling and so forth.
2) Unlike the Linux Kernel, which Linus uses as a prime example of
something git is very useful for, the Rockbox project has no central
figurehead for anyone to consider as owning the "master" repository
from which to build the "current" version of the Rockbox firmware for
any given target.
3) With a central repository, for which we have a limited number of
individuals having commit access, it's easy for us to automate a build
based on each commit the repository receives.
Given these three points, we wonder how we'd best achieve the same
using git. As far as we can make out we'd need to appoint someone as a
maintainer for a master repository whose job it is to co-ordinate
pulls from people based on when they've made changes we wish to
include in the latest version of our software. This sounds like a time
consuming role for a project which is only staffed by volunteers.
Can anyone offer any insights for us here?
Bryan
^ 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