* Re: gitweb css - pixels?!
From: Jan Hudec @ 2007-05-08 8:36 UTC (permalink / raw)
To: Chris Riddoch; +Cc: git
In-Reply-To: <6efbd9b70705071613p23017509qaf9af12c1d14f9cb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
On Mon, May 07, 2007 at 17:13:42 -0600, Chris Riddoch wrote:
> Hi, folks.
>
> I've been gradually converting my ~/src directory full of tarballs
> I've found interesting enough to download to a ~/repos/ directory
> containing bare git repositories of the projects. I was thinking it
> might be worth my while to set up gitweb so I can peruse my collection
> of projects.
>
> I noticed myself squinting, on my 1400x1050 laptop screen, at the 10
> and 12-*pixel* font settings gitweb's CSS specifies before thinking to
> myself that I should bring this to the list's attention.
>
> I'm no CSS guru, or I'd just provide a patch. It seems that *all* the
> measurements specified in the CSS file are in pixels, not ems or
> percentages. There's got to be a better way. I can't be the only
> person who would rather use my nice screen to render attractive,
> readable fonts rather than to render the smallest possible fonts?
Well, there should be three ways to set font sizes:
1. Use the symbolic small, normal, large..., which are derived from user
settings (normal is user setting, large is one step larger etc.). IMHO
this would be the best variant.
2. Use *points* (pt) instead of *pixels* (px). Unfortunately most browsers
don't know what their DPI is and will treat 1pt as 1px, even though they
have more than 72dpi. I believe this applies to all Micro$oft browsers.
3. Use designation relative to previous font. One step up is 1.2em, one step
down is 0.8333333em. I am not sure this actually works in Micro$oft
browsers. Also rounding errors may quickly get you to completely
different font size that you wanted.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] user-manual.txt: Some doc updates
From: Santi Béjar @ 2007-05-08 8:37 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Git Mailing List
In-Reply-To: <20070508032115.GC9471@fieldses.org>
On 5/8/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Thu, Apr 19, 2007 at 05:49:40PM +0200, Santi Béjar wrote:
> > git branch::
> > + list all local branches
> > +git branch -r::
> > + list all remote branches
> > +git branch -a::
> > list all branches
>
> I think I dropped this just because "remote branches" haven't yet been
> introduced at this point in the manual. (That's not till "Examining
> branches from a remote repository".) Could be some sections should be
> reordered--suggestions welcomed.
OK.
>
> > +-------------------------------------------------
> > +$ git diff HEAD
> > +-------------------------------------------------
> > +
> > +shows the difference between the working tree and HEAD.
> > +
>
> I took the mention of this later on, but didn't think it was necessary
> to mention here too.
Fair enough.
>
> > @@ -1872,10 +1880,7 @@ As with git-fetch, you may also set up configuration options to
> > save typing; so, for example, after
> >
> > -------------------------------------------------
> > -$ cat >.git/config <<EOF
> > -[remote "public-repo"]
> > - url = ssh://yourserver.com/~you/proj.git
> > -EOF
> > +$ git config remote."public-repo".url ssh://yourserver.com/~you/proj.git
> > -------------------------------------------------
>
> I think this was adequately discussed.
>
OK.
> > +You can also instantly browse your working repository in gitweb using:
> > +
> > +-------------------------------------------------
> > +$ git instaweb
> > +-------------------------------------------------
> > +
> > +See gitlink:git-instaweb[1] for details.
> > +
>
> That's nifty, but doesn't seem necessary at this point, and doesn't
> quite fit in the section (which is about public repositories).
>
I've put it here because then you can view the gitweb before public
consumption. Otherwise OK.
> Others look good, thanks.
>
> But if you want whole patches applied or rejected with explanation, I
> think you may have to be prepared to revise and resubmit when there are
> objections to parts.
Yes and I have already prepared the remaining patch, but first I need
to know the objections.
Santi
^ permalink raw reply
* Re: git-svn: importing branches later
From: Karl Hasselström @ 2007-05-08 8:51 UTC (permalink / raw)
To: git
In-Reply-To: <20070507190702.GE342@ginosko.local>
On 2007-05-07 13:07:06 -0600, Michael Hendricks wrote:
> Now I want to import the 'foo' branch from the same SVN repo without
> grabbing all the branches. Any suggestions?
I seem to recall that just adding another "fetch" line to the git-svn
configuration in .git/config will do this for you.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Alex Riesen @ 2007-05-08 9:08 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <4640015F.1080407@gmail.com>
On 5/8/07, Liu Yubao <yubao.liu@gmail.com> wrote:
> +#ifdef __CYGWIN__
> + /*
> + * On cygwin, lstat("hello", &st) returns 0 when
> + * "hello.exe" exists, so test with open() again.
> + */
> + if (lstat(match, &st) && -1 != (fd = open(match, O_RDONLY))) {
This does not "test again" if lstat returns 0. If lstat returns 0
(file stat info
obtained) the open is not even called. Besides, cygwin lies not only about
.exe but also about .lnk files.
P.S. Somehow I have the feeling that even if it is a stupidity in cygwin
they will not fix it (nor will they admit it is a bug).
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Jan Hudec @ 2007-05-08 9:39 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <4640015F.1080407@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 513 bytes --]
On Tue, May 08, 2007 at 12:49:35 +0800, Liu Yubao wrote:
> +#ifdef __CYGWIN__
> + /*
> + * On cygwin, lstat("hello", &st) returns 0 when
> + * "hello.exe" exists, so test with open() again.
> + */
> + if (lstat(match, &st) && -1 != (fd = open(match, O_RDONLY))) {
> + struct dir_entry *ent;
> + close(fd);
> +#else
> if (!lstat(match, &st)) {
> struct dir_entry *ent;
> -
> +#endif
You seem to have reversed the sense of the test.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Yet another git perforce integration
From: Alex Riesen @ 2007-05-08 9:47 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200705081023.38810.simon@lst.de>
On 5/8/07, Simon Hausmann <simon@lst.de> wrote:
>
> git-p4 submit
>
> is used to submit changes back into Perforce (use at your own risk! :)
right, because you have to know where (and when) your perforce repo is,
and then where and when your copy (in Git) is, copy the p4 changes,
rebase your changes on top of the just copied changes (p4 history
is linear), try to submit, watch out for fails, because someone else could
have submitted something, possibly resync and repeat. Cursing and
swearing notwithstanding.
I simplified the operation by promising to hit everyone who submits
anything in my domain (and was supported by the local P4 sysadms,
so it worked).
> The import itself uses git-fast-import, so it's very fast. There is also no
> need to have the imported Perforce projects in the Perforce client view as it
> just uses "p4 changes //depot/path" and "p4
> print //depot/path/file#revision", which I find very convenient and still
> fast enough for use (since of course only changed files are printed).
I confirm that, but could not use the same approach in git-p4-import
I posted earlier: I don't control the sync operation, and the stupid prog
that does the sync does not allow in-client operation (p4 sync -n).
I just have to work somehow with the junk it left in working directory
> It also doesn't require any additional meta-data. Instead every import commit
> has a line added to the log message that contains the Perforce path the
> changeset comes from as well as the change number. git-p4
> sync/rebase "parses" this on the last commit in the "p4" git branch to find
> out where to continue importing for incremental imports.
How do you handle that patchwork of mappings synced to diverse revisions
that P4 clients tend to become? Don't you have to save change number or
revision for _each_ file?
> What's still missing is a bit of cleanup. For example I'd like to put the
> import branch into refs/remotes instead of refs/heads, but I've had some
> problems with fast-import when trying that. Also the support for Perforce
> branches isn't quite working yet.
AFACS, it is impossible: Perforce does not have branches (in Git's meaning
of the word). It only has directories. Integration (it is something like
"in-repo-copy") metadata are just duct-taped on it (that stupid branchspec).
> Also I've never tried it on Windows and I expect problems as the script uses
> pipes, calls "patch", etc.
...and case-sensitivity. BTW, how does your script handle filenames with
special characters and spaces in them?
^ permalink raw reply
* minimize_url in git-svn?
From: Junio C Hamano @ 2007-05-08 9:58 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <464023D4.5060101@midwinter.com>
I was trying to run git-svn against this:
https://repo.socialtext.net:8999/svn/socialtext/trunk
This is an open source project [*1*] and the trunk is supposed
to be readable by everybody, but it seems that anything outside
that area needs authentication. If I mimick the example in
git-svn.txt manual page to clone from there, it creates trunk,
trunk/.git, and then asks for password:
$ URL=https://repo.socialtext.net:8999/svn/socialtext/trunk
$ git-svn clone $URL
Authentication realm: <https://repo.socialtext.net:8999> Auth for SVN
Password for 'junio': ^C
I've narrowed it down to this part of git-svn. If I tell it not
to bother "minimiz"ing the URL, it seems to import without
stepping outside of the URL it was given.
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1038,7 +1038,8 @@
}
$self->{repo_id} = $existing;
} else {
- my $min_url = Git::SVN::Ra->new($url)->minimize_url;
+ my $ra = Git::SVN::Ra->new($url);
+ my $min_url = $url; # $ra->minimize_url;
$existing = find_existing_remote($min_url, $r);
if ($existing) {
unless ($no_write) {
Two and half questions.
* What does minimize do, and why is it necessary?
* The resulting git-svn remote tracking branch (and 'master')
seems to check out fine, but I do not know what damage the
hack to avoid minimizing is causing. Are there any? I see
many 0{40} lines in trunk/.git/svn/git-svn/.rev_db.* file,
and also many lines in unhandled.log file (+empty_dir,
+file_prop, and +dir_prop). Are these something to worry
about?
* Assuming there aren't any damage, or maybe some damage that
would cause minor decreased functionality/interoperability,
would it perhaps make sense to optionally allow skipping the
minimizing to avoid this problem? Would it make sense, or is
the setting at socialtext site too esoteric and it isn't
worth to worry about?
[Footnote]
*1* http://www.socialtext.net/stoss/index.cgi?developing_with_a_dev_env
^ permalink raw reply
* Re: [PATCH] wcwidth redeclaration
From: Johannes Schindelin @ 2007-05-08 10:03 UTC (permalink / raw)
To: Amos Waterland; +Cc: Junio C Hamano, git
In-Reply-To: <7vmz0f52no.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 7 May 2007, Junio C Hamano wrote:
> apw@us.ibm.com (Amos Waterland) writes:
>
> > Build fails for git 1.5.1.3 on AIX, with the message:
> >
> > utf8.c:66: error: conflicting types for 'wcwidth'
> > /.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here
> >
> > Here is a patch that fixes it for me. If there is a different way that
> > is preferred, please let me know.
>
> It's static in that file, so renaming our version to our own
> name as you did is perfectly good.
>
> Thanks for helping, as not many people seem to be on AIX on this
> list.
Thanks indeed. I thought that a static function could shadow a global
function, but probably not with a different signature. Just out of
curiosity: what is the signature of wcwidth in your string.h?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] user-manual: fix clone and fetch typos
From: Karl Hasselström @ 2007-05-08 10:12 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Santi Béjar, git
In-Reply-To: <20070508034129.GE9471@fieldses.org>
On 2007-05-07 23:41:29 -0400, J. Bruce Fields wrote:
> Hm. I still see
>
> Content-Type: text/plain; charset=iso-8859-1
>
> in the headers
But this time, it looks good to me. This is probably because the
headers say the body is QP-encoded latin1:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
and the body actually _is_ QP-encoded latin1:
More typo fixes from Santi B=E9jar
Note how the "é" is encoded with only one byte this time, like it's
supposed to in latin1.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Jan Hudec @ 2007-05-08 10:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Liu Yubao, git
In-Reply-To: <81b0412b0705080208x3713cbc1y3c870383b586c877@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
On Tue, May 08, 2007 at 11:08:35 +0200, Alex Riesen wrote:
> On 5/8/07, Liu Yubao <yubao.liu@gmail.com> wrote:
> >+#ifdef __CYGWIN__
> >+ /*
> >+ * On cygwin, lstat("hello", &st) returns 0 when
> >+ * "hello.exe" exists, so test with open() again.
> >+ */
> >+ if (lstat(match, &st) && -1 != (fd = open(match,
> >O_RDONLY))) {
>
> This does not "test again" if lstat returns 0. If lstat returns 0
> (file stat info
> obtained) the open is not even called. Besides, cygwin lies not only about
> .exe but also about .lnk files.
>
> P.S. Somehow I have the feeling that even if it is a stupidity in cygwin
> they will not fix it (nor will they admit it is a bug).
They will not. Because it is not a bug. It seems to be (part of) workaround
to get programs written for unix work in windows.
One reason for such workaround I can think of is, that some programs try to
find themselves and since their argv[0] often does NOT contain the extension,
the stat has to succeed for them.
Using open here unfortunately won't work though, because:
- For stale links open will fail, but the lstat should succeed. This does
apply to cygwin, because cygwin emulates links.
- I'd expect open to actually succeed in this case, because there are
programs that don't only try to find themselves, but also open themselves,
because they bundle some data.
Another problem is, that the file might exist or might be cygwin artefact and
there does not seem to be an easy way to tell.
IMHO the described problem is harmless (you know the file does not exist, so
you should have no reason to add it and nothing happens if you don't) and
happens very rarely (adding binaries to version control is usually not a good
idea), so I suggest to let this be, as the workaround can easily cause other
problems.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Karl Hasselström @ 2007-05-08 10:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <464023A1.6618BC0A@eudaptics.com>
On 2007-05-08 09:15:45 +0200, Johannes Sixt wrote:
> "Shawn O. Pearce" wrote:
>
> > But I'm glad someone else finds the hunk feature useful in
> > git-gui. I use it far too often myself.
>
> It it among the most-wanted features here. We discovered it only
> because Karl mentioned it yesterday. ;)
See? Who said spamming doesn't work? :-)
I think it would be worth introducing git-gui as a commit tool in the
tutorial(s) and the manual. It gives a very nice graphical
representation of the dirty state you're going to commit, and the
dirty state you aren't going to commit because you haven't staged it
yet. The only drawback is that it's a lot of work to make
documentation with screenshots ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Ismail Dönmez @ 2007-05-08 10:49 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 309 bytes --]
Hi,
According to FHS standard default man page path is $prefix/share/man [0] ,
attached patch fixes this for GIT.
[0] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
Signed-off-by: Ismail Donmez <ismail@pardus.org.tr>
Regards,
ismail
--
Le mieux est l'ennemi du bien.
[-- Attachment #1.2: mandir.patch --]
[-- Type: text/x-diff, Size: 309 bytes --]
--- Documentation/Makefile 2007-02-26 21:20:28.000000000 +0200
+++ Documentation/Makefile 2007-02-28 01:18:07.672166995 +0200
@@ -26,7 +26,7 @@
prefix?=$(HOME)
bindir?=$(prefix)/bin
-mandir?=$(prefix)/man
+mandir?=$(prefix)/share/man
man1dir=$(mandir)/man1
man7dir=$(mandir)/man7
# DESTDIR=
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Yet another git perforce integration
From: Simon Hausmann @ 2007-05-08 10:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0705080247l2385529t61ad4ecd083261c7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4397 bytes --]
On Tuesday 08 May 2007 11:47:31 Alex Riesen wrote:
> On 5/8/07, Simon Hausmann <simon@lst.de> wrote:
> > git-p4 submit
> >
> > is used to submit changes back into Perforce (use at your own risk! :)
>
> right, because you have to know where (and when) your perforce repo is,
> and then where and when your copy (in Git) is, copy the p4 changes,
> rebase your changes on top of the just copied changes (p4 history
> is linear), try to submit, watch out for fails, because someone else could
> have submitted something, possibly resync and repeat. Cursing and
> swearing notwithstanding.
Yeah, it's a bit tricky. I'm using "p4 where" to locate the p4 checkout and
submitting back to perforce is an interactive process for me. The user is
presented with the entire diff for each change as well as the log message in
an editor and can also abort/continue in-between. In real-life usage I've
found it to be fairly smooth though (no or only few conflits), but then I
guess it depends also on the number of people working on the depot as a whole
at the same time :)
> > It also doesn't require any additional meta-data. Instead every import
> > commit has a line added to the log message that contains the Perforce
> > path the changeset comes from as well as the change number. git-p4
> > sync/rebase "parses" this on the last commit in the "p4" git branch to
> > find out where to continue importing for incremental imports.
>
> How do you handle that patchwork of mappings synced to diverse revisions
> that P4 clients tend to become? Don't you have to save change number or
> revision for _each_ file?
I'm not sure I understand the question. I don't really use the p4 client view
at all. I know the last imported p4 change number from the top commit in the
git "p4" branch. Then I use "p4 changes //depot/path/@lastchangenum,#head" to
get the list of changes that need to be imported. For each change I look at
the list of affected files using "p4 describe" and feed each file using "p4
print" into git-fast-import. None of these import operations require anything
from the client view/mapping.
Only when submitting changes back to Perforce the corresponding depot path
must be checked out /somewhere/ (!= git repository), so that "p4
where //depot/path" reports it. But then I just offer the user to run "p4
sync" before applying the changes from git.
I guess the feasibility may very well depend a bit on the development model
used with p4. I don't know if there are many models, but for example we have
a fairly linear model where it's normal to be at the #head revision, don't
use a whole lot of branches in Perforce. So p4 users are used to running "p4
resolve" and I personally got used to git conflict resolving through "git
rebase" :)
> > What's still missing is a bit of cleanup. For example I'd like to put the
> > import branch into refs/remotes instead of refs/heads, but I've had some
> > problems with fast-import when trying that. Also the support for Perforce
> > branches isn't quite working yet.
>
> AFACS, it is impossible: Perforce does not have branches (in Git's meaning
> of the word). It only has directories. Integration (it is something like
> "in-repo-copy") metadata are just duct-taped on it (that stupid
> branchspec).
True, it probably depends a bit on the depot organization. For example we have
//depot/qt/main and then branches like //depot/qt/4.3 or research branches
like //depot/qt/research/somecoolfeature . That's the kind of structure I'd
like to map to git, and merges /could/ be detected from integrations if after
a commit that has integrations between these "known" branches all revisions
of all files are integrated. But that's obviously a very slow operation and I
currently don't think it's worth it. But of course detecting the initial
branch point is easy and fast and that is worth it (to record the branch
creation, there's no merge of course).
> > Also I've never tried it on Windows and I expect problems as the script
> > uses pipes, calls "patch", etc.
>
> ...and case-sensitivity. BTW, how does your script handle filenames with
> special characters and spaces in them?
I don't really treat them special. I get the file name from the output of "p4
describe" (using the Guido option :) and pass it on to git-fast-import.
Simon
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-08 11:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com>
Hi,
On Tue, 8 May 2007, Martin Langhoff wrote:
> Heh. Making the index very visible makes sense when you are merging,
You're saying that the main use of the index is to help merging. I have to
disagree strongly.
When I have been chasing a bug all over the place, and finally found it,
my working tree is a mess. Lots of assertions, lots of debugging
statements, some of them commented out. So, now it is cleanup time, right?
The problem is that more often than not, I broke my fix while cleaning up.
Therefore, I now put all changed files into the index (git add -u), and
clean up the files one by one, always checking with "git diff" and "git
diff HEAD" what I still have to do.
Yes, very often I can just take the original version of a file (git reset
--soft <file...> would be handy here), but it helped me quite a number of
times to have my messed-up-but-working state in the index.
In a sense, I am using the index as the stash commit we talked about every
once in a while.
Ciao,
Dscho
^ permalink raw reply
* gitk and git-gui, was Re: FFmpeg considering GIT
From: Johannes Schindelin @ 2007-05-08 11:16 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Paul Mackerras, Brett Schwarz, Linus Torvalds, Karl Hasselstr?m,
Junio C Hamano, Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <20070508041939.GK11311@spearce.org>
Hi,
On Tue, 8 May 2007, Shawn O. Pearce wrote:
> Paul Mackerras <paulus@samba.org> wrote:
>
> > Gitk ends up handling pretty significant amounts of data. In
> > particular the per-commit data can get to gigabytes, and processing it
> > is pretty cpu-intensive. I did try using namespaces for the
> > per-commit data but I found that the performance hit to be more than I
> > was willing to tolerate.
>
> If that is the case then an obvious direction is to start using C for
> the actual Git operations/datastore and Tcl/Tk for the basic UI layout
> and event handlers.
It might be a much better idea to write something a la git-fetch--tool,
which is a helper in C (thus very fast and memory efficient), outputting
easily parseable data.
For example, when constructing the commit graph, the calculations could be
done in C, and Tcl/Tk could do _just_ the display. AFAIK tig already has
the algorithm implemented in C...
The big benefits would not only be that you can compile this without the
headers/libs of Tcl/Tk (possibly avoiding the problem we experienced when
trying to compile Git with gcc, and linking to Perl, which was compiled
with a different compiler), but other Git viewers could take this output
as well, avoiding reimplementing the algorithm in Ruby or Haskell.
Ciao,
Dscho
^ permalink raw reply
* Re: minimize_url in git-svn?
From: Johannes Schindelin @ 2007-05-08 11:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7v4pmn4oxj.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Tue, 8 May 2007, Junio C Hamano wrote:
> I was trying to run git-svn against this:
>
> https://repo.socialtext.net:8999/svn/socialtext/trunk
>
> This is an open source project [*1*] and the trunk is supposed
> to be readable by everybody, but it seems that anything outside
> that area needs authentication. If I mimick the example in
> git-svn.txt manual page to clone from there, it creates trunk,
> trunk/.git, and then asks for password:
>
> $ URL=https://repo.socialtext.net:8999/svn/socialtext/trunk
> $ git-svn clone $URL
> Authentication realm: <https://repo.socialtext.net:8999> Auth for SVN
> Password for 'junio': ^C
FWIW I encountered the same problem with tailor.
Ciao,
Dscho
^ permalink raw reply
* Re: How to set git commit timestamp
From: Johannes Schindelin @ 2007-05-08 11:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20070508015702.GE11311@spearce.org>
Hi,
On Mon, 7 May 2007, Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > By the way, is there fast-import version of git-quiltimport?
>
> No, and I don't think its easy. Isn't a quilt patchstack stored as a
> series of patch files? So "importing" it into Git requires applying the
> patch to the base tree, then writing that base tree to the ODB.
> fast-import doesn't know how to run git-apply, though Junio and I did
> kick it around (generally) a few months ago on #git.
You'd have to pretend that all of these patches are branches. Well, in the
end they are...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-gui: Call changes "Staged" and "Unstaged" in file list titles.
From: Johannes Sixt @ 2007-05-08 11:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
From: Johannes Sixt <johannes.sixt@telecom.at>
All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I hope the patch went through without my MUA's "improvements".
Hannes
git-gui/git-gui.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 60e79ca..45d251e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -5494,7 +5494,7 @@ pack .vpane -anchor n -side top -fill both -expand 1
# -- Index File List
#
frame .vpane.files.index -height 100 -width 200
-label .vpane.files.index.title -text {Changes To Be Committed} \
+label .vpane.files.index.title -text {Staged Changes (Will Be Committed)} \
-background green \
-font font_ui
text $ui_index -background white -borderwidth 0 \
@@ -5516,7 +5516,7 @@ pack $ui_index -side left -fill both -expand 1
# -- Working Directory File List
#
frame .vpane.files.workdir -height 100 -width 200
-label .vpane.files.workdir.title -text {Changed But Not Updated} \
+label .vpane.files.workdir.title -text {Unstaged Changes (Will Not Be Committed)} \
-background red \
-font font_ui
text $ui_workdir -background white -borderwidth 0 \
--
1.5.1.1.27.g91776
^ permalink raw reply related
* Re: [PATCH] remove unnecessary loop
From: Eric Blake @ 2007-05-08 12:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: Liu Yubao, git
In-Reply-To: <81b0412b0705080208x3713cbc1y3c870383b586c877@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Alex Riesen on 5/8/2007 3:08 AM:
> This does not "test again" if lstat returns 0. If lstat returns 0
> (file stat info
> obtained) the open is not even called. Besides, cygwin lies not only about
> .exe but also about .lnk files.
>
> P.S. Somehow I have the feeling that even if it is a stupidity in cygwin
> they will not fix it (nor will they admit it is a bug).
It is a limitation of cygwin, and the cygwin developers will admit it; but
they will also stand behind calling it a feature rather than a bug due to
the attempts to make cygwin behave more like Linux in spite of Window's
insistence on file suffixes. The cygwin port of coreutils has to do
similar stat() tricks to reverse engineer some of the .exe magic present
in cygwin. However, it is possible to override the magic without
resorting to a full-blown open(), via careful use of additional stat()s or
readlink()s (trailing . is not legal in Windows, and on cygwin is only
legal on managed mounts, so stat("foo.") will fail when stat("foo")
succeeds if the reason stat("foo") succeeded was due only to the existence
of foo.exe):
/* Return -1 if PATH not found, 0 if PATH spelled correctly, and 1 if PATH
had ".exe" automatically appended by cygwin. Don't change errno. */
int
cygwin_spelling (char const *path)
{
char path_exact[PATH_MAX + 9];
int saved_errno = errno;
int result = 0; /* Start with assumption that PATH is okay. */
int len = strlen (path);
if (! path || ! *path || len > PATH_MAX)
/* PATH will cause EINVAL or ENAMETOOLONG, treat it as non-existing. */
return -1;
if (path[len - 1] == '.' || path[len-1] == '/')
/* Don't change spelling if there is a trailing `.' or `/'. */
return 0;
if (readlink (path, NULL, 0) < 0)
{ /* PATH is not a symlink. */
if (errno == EINVAL)
{ /* PATH exists. Appending trailing `.' exposes whether it is
PATH or PATH.exe for normal disk files, but also check appending
trailing `.exe' to be sure on virtual/managed directories. */
strcat (strcpy (path_exact, path), ".");
if (access (path_exact, F_OK) < 0)
{ /* PATH. does not exist. */
strcat (path_exact, "exe");
if (access (path_exact, F_OK) == 0)
/* But PATH.exe does, so append .exe. */
result = 1;
}
}
else
/* PATH does not exist. */
result = -1;
}
else
{ /* PATH is a symlink. Appending trailing `.lnk' exposes whether
it is PATH.lnk or PATH.exe.lnk; but does not help with
old-style symlinks where it was just PATH and the system
attribute set. */
strcat (strcpy (path_exact, path), ".lnk");
if (readlink (path_exact, NULL, 0) < 0)
{
strcat (strcpy (path_exact, path), ".exe.lnk");
if (readlink (path_exact, NULL, 0) == 0)
result = 1;
}
}
errno = saved_errno;
return result;
}
In the upcoming cygwin 1.7.0, you can set CYGWIN=transparent_exe which
will cause ENOENT when dealing with any explicit .exe. When enabled, that
will make it impossible to have both foo and foo.exe in the current
directory, and make it so that stat can never lie - stat("foo.exe") will
fail, and if stat("foo") succeeds, you no longer care if it succeeded
because of the Windows file foo or because of foo.exe, because the .exe is
transparent to cygwin.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGQGpH84KuGfSFAYARAsCdAKCmqdgsppPY0MhxDWZ6QQxXExn2gwCeLN39
Zl3sRk/0IkkHkIyjf4RpAAA=
=rQrT
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Yet another git perforce integration
From: Alex Riesen @ 2007-05-08 12:32 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200705081249.36214.simon@lst.de>
On 5/8/07, Simon Hausmann <simon@lst.de> wrote:
> > > It also doesn't require any additional meta-data. Instead every import
> > > commit has a line added to the log message that contains the Perforce
> > > path the changeset comes from as well as the change number. git-p4
> > > sync/rebase "parses" this on the last commit in the "p4" git branch to
> > > find out where to continue importing for incremental imports.
> >
> > How do you handle that patchwork of mappings synced to diverse revisions
> > that P4 clients tend to become? Don't you have to save change number or
> > revision for _each_ file?
>
> I'm not sure I understand the question. I don't really use the p4 client view
> at all. ...
Ah, you're _that_ lucky...
> > > problems with fast-import when trying that. Also the support for Perforce
> > > branches isn't quite working yet.
> >
> > AFACS, it is impossible: Perforce does not have branches (in Git's meaning
> > of the word). It only has directories. Integration (it is something like
> > "in-repo-copy") metadata are just duct-taped on it (that stupid
> > branchspec).
>
> True, it probably depends a bit on the depot organization. For example we have
> //depot/qt/main and then branches like //depot/qt/4.3 or research branches
> like //depot/qt/research/somecoolfeature . That's the kind of structure I'd
> like to map to git, ...
Recreating it anywhere, not just in Git, would be stupid. As it is in Perforce.
> > > Also I've never tried it on Windows and I expect problems as the script
> > > uses pipes, calls "patch", etc.
> >
> > ...and case-sensitivity. BTW, how does your script handle filenames with
> > special characters and spaces in them?
>
> I don't really treat them special. I get the file name from the output of "p4
> describe" (using the Guido option :) and pass it on to git-fast-import.
>
You seem to assume that the names never contain double quotes and
backslashes. For example in the names of directories.
^ permalink raw reply
* Re: [PATCH/RFC] diff: Make numstat machine friendly also for renames
From: Jakub Narebski @ 2007-05-08 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcqo5b64.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>>> The numstat format for rename is now
>>>>
>>>> added deleted TAB path for "src" TAB path for "dst" LF
>>>>
>>>> or if -z option is used
>>>>
>>>> added deleted TAB path for "src" NUL NUL path for "dst" NUL
>>>
>>> Why two NULs?
>>
>> That was the only way I could think of to separate pre-image name
>> from posi-image name for renames. Note that file name might look like
>> (part of) diffstat line, and there is no 'status' field in the
>> numstat to mark rename (as there is in "git diff-tree --raw" output).
>
> The --stat format is for human consumption, and --numstat (be it
> with -z or without) is for machines, so I am not opposed to a
> format change that gives information that is already computed
> but currently is hard to parse. If the format change breaks
> existing scripts, we might want to do --numstat-extended,
> though...
>
> For example, I do not see a reason not to add "R98" in there.
> I.e.
>
> added deleted status TAB "src" (TAB "dst"){0,1} LF
> added deleted status NUL "src" (NUL "dst"){0,1} NUL
>
> where the dst path is present only when status says it is a
> rename/copy, just like the --raw format.
That is a good idea, but wouldn't it break existing scripts? Well,
break more than a bit hacky idea of using NUL NUL as separator between
pre-image name and post-image name.
This would change output in every case, while my proposal doesn't change
output for the case without renames. '-M' should also work correctly,
perhaps scripts using it getting wrong filename. It is '-z -M' that changes
most.
>> Did you mean --stat here?
>
> No, I did mean --summary. But that was foolish of me. I forgot
> that it had the same { namepart => namepart } issue.
Ah. I somehow didn't get then that you meant for --numstat to have only
post-image names, and get pre-image names from rename information in
--summary. But as you have noticed it wouldn't help: rename information
is in the same for-humans format.
>>>> @@ -949,11 +955,19 @@ static void show_numstat(struct diffstat_t* data,
>>>> printf("-\t-\t");
>>>> else
>>>> printf("%d\t%d\t", file->added, file->deleted);
>>>> - if (options->line_termination && !file->is_renamed &&
>>>> + if (options->line_termination &&
>>>> quote_c_style(file->name, NULL, NULL, 0))
>>>> quote_c_style(file->name, NULL, stdout, 0);
>>>> else
>>>> fputs(file->name, stdout);
>>>> + if (file->is_renamed) {
>>>> + printf("%s", options->line_termination ? "\t" : "\0\0");
>
> What I was hoping you to notice was that printf("%s", "\0\0")
> thing. %s would not even notice that the const char[] literal
> is 2 bytes long.
Ooops. Shame on me. That is the result of trying to be too smart...
and changing separator between pathnames for rename from NUL to NUL NUL.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] remove unnecessary loop
From: Alex Riesen @ 2007-05-08 12:38 UTC (permalink / raw)
To: Jan Hudec; +Cc: Liu Yubao, git
In-Reply-To: <20070508101317.GC9007@efreet.light.src>
On 5/8/07, Jan Hudec <bulb@ucw.cz> wrote:
> >
> > P.S. Somehow I have the feeling that even if it is a stupidity in cygwin
> > they will not fix it (nor will they admit it is a bug).
>
> They will not. Because it is not a bug. It seems to be (part of) workaround
> to get programs written for unix work in windows.
>
Just as I said. Why don't you just realize that windows is plainly
stupid, illogical piece of sh%t and state clearly that people have to
break their programs so-and-so to work there? Instead, everyone
has to put the most stupid workarounds POSIX ever seen in their
code just to get core functionality (which even HP-UX got right).
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: J. Bruce Fields @ 2007-05-08 12:40 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Johannes Sixt, git
In-Reply-To: <20070508102836.GB27119@diana.vm.bytemark.co.uk>
On Tue, May 08, 2007 at 12:28:36PM +0200, Karl Hasselström wrote:
> I think it would be worth introducing git-gui as a commit tool in the
> tutorial(s) and the manual. It gives a very nice graphical
> representation of the dirty state you're going to commit, and the
> dirty state you aren't going to commit because you haven't staged it
> yet. The only drawback is that it's a lot of work to make
> documentation with screenshots ...
You could put that on a web page someplace.
For the tutorial and user manual, could git-gui be treated similar gitk,
with just a one- or two- line mention here and there? I haven't used
it, so don't know where it would most logically fit in....
--b.
^ permalink raw reply
* [PATCH] Add --no-reuse-delta option to git-gc
From: Theodore Ts'o @ 2007-05-08 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <11786309072612-git-send-email-tytso@mit.edu>
This allows the user to regenerate the deltas in packs while doing
a git-gc. The user could just run git-repack -a -d -f -l after
running git-gc, but then the first git-repack run by git-gc is
a bit of waste.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
Documentation/git-gc.txt | 7 ++++++-
builtin-gc.c | 24 ++++++++++++++++++++++--
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index bc16584..0493d06 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
-'git-gc' [--prune]
+'git-gc' [--prune] [--no-reuse-delta]
DESCRIPTION
-----------
@@ -35,6 +35,11 @@ OPTIONS
repository at the same time (e.g. never use this option
in a cron script).
+--no-reuse-delta::
+ This causes deltas in existing packs to be recalculated instead
+ of reusing the existing deltas. This can save disk space at
+ the cost of taking more time to recalculate them from scratch.
+
Configuration
-------------
diff --git a/builtin-gc.c b/builtin-gc.c
index 3b1f8c2..5cb7ffd 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -15,13 +15,14 @@
#define FAILED_RUN "failed to run %s"
-static const char builtin_gc_usage[] = "git-gc [--prune]";
+static const char builtin_gc_usage[] = "git-gc [--prune] [--no-reuse-delta]";
static int pack_refs = -1;
+#define MAX_ADD 10
static const char *argv_pack_refs[] = {"pack-refs", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
-static const char *argv_repack[] = {"repack", "-a", "-d", "-l", NULL};
+static const char *argv_repack[MAX_ADD] = {"repack", "-a", "-d", "-l", NULL};
static const char *argv_prune[] = {"prune", NULL};
static const char *argv_rerere[] = {"rerere", "gc", NULL};
@@ -37,6 +38,21 @@ static int gc_config(const char *var, const char *value)
return git_default_config(var, value);
}
+static append_option(const char **cmd, const char *opt, int max_length)
+{
+ int i;
+
+ for (i=0; cmd[i]; i++)
+ ;
+
+ if (i+2 >= max_length) {
+ fprintf(stderr, "Too many options specified\n");
+ exit(1);
+ }
+ cmd[i++] = opt;
+ cmd[i] = 0;
+}
+
int cmd_gc(int argc, const char **argv, const char *prefix)
{
int i;
@@ -53,6 +69,10 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
prune = 1;
continue;
}
+ if (!strcmp(arg, "--no-reuse-delta")) {
+ append_option(argv_repack, "-f", MAX_ADD);
+ continue;
+ }
/* perhaps other parameters later... */
break;
}
--
1.5.2.rc2.22.ga39d
^ permalink raw reply related
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to
From: Theodore Ts'o @ 2007-05-08 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr6ps3oyk.fsf@assigned-by-dhcp.cox.net>
OK, here's a patch to implement pack.depth (with the default tweaked
to 50 --- is that too high?), followed by a simplified and reworked
patch to git-gc that only implements --no-reuse-delta.
I don't imagine that most users will want to use that feature most of
the time, hence the long option name, but occasionally, it might be
useful. Yes, the user could just run "git-repack -a -d -f -l" after
running git-gc, but then the "git-repack -a -d -l" in git-gc is just a
wasted disk i/o. I don't know if I'll manage to convince you, if not,
just drop the second patch, I guess. :-)
- Ted
^ 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