* Re: Problem with git-apply?
From: Kevin Shanahan @ 2006-11-04 8:07 UTC (permalink / raw)
To: git
In-Reply-To: <20061104072349.GA19667@cubit>
On Sat, Nov 04, 2006 at 05:53:49PM +1030, Kevin Shanahan wrote:
> I seem to be having problems using git-apply to apply any patch which
> creates a new file. Unfortunately it's been a few weeks since I last
> used git here locally, but this seems like some behaviour change since
> the last version I was using. I'm currently using version 1.4.3.3 from
> Debian Sid. This little test script demonstrates the problem I'm
> having:
Sorry, I probably should have said to CC me, as I'm not subscribed.
Thanks for your reply Shawn, but --index doesn't seem to make any
difference. If it helps, I can confirm that the script works fine with
version 1.4.1.1.
> #!/bin/sh
>
> mkdir a b repo
> echo foo > b/foo
> diff -urN a b > test.diff
>
> (
> cd repo
> echo bar > bar # need something to init the db
> git init-db
> git add .
> git commit -a -m "Test Commit"
>
> git apply ../test.diff
> git commit -a -m "Test Commit (file added)"
> )
>
> Here, this outputs for me:
>
> defaulting to local storage area
> Committing initial tree ee314a31b622b027c10981acaed7903a3607dbd4
> error: foo: No such file or directory
> nothing to commit
>
> Has something broken or am I doing something wrong here?
>
> Thanks,
^ permalink raw reply
* Re: git and branches newie questions
From: Alan Chandler @ 2006-11-04 7:46 UTC (permalink / raw)
To: git
In-Reply-To: <6844644e0611020902tc6251f7i2eda0d3fc82e0502@mail.gmail.com>
On Thursday 02 November 2006 17:02, Doug Reiland wrote:
...
> I want to use internal_testing as a branch to merge and test the
> latest Linux branch with changes made to internal_current. Once this
> testing is complete, merge the changes into internal_current.
>
> That is the best way to do this. I am open to use cogito. I have
> messed up this merging process just about each time, and I want to get
> a stable process before I open this up to other users.
I notice that nobody has responded to your questions and a couple of days have
gone past, and whilst I am not sure I know enough to respond correctly, I
will do so to keep the thread alive so that perhaps someone more
knowledgeable than me can comment too.
It sounds as though you are setting up a central repository type concept. So
why try and do the work of merging Linus' repository there? Why not clone
from Linus in a local repository, merge in changes from this common
repository into your local repository and test, and when happy push them back
out to the common one?
>
> Also, I can't figure out permissions. I have setup the allow_users
> hook in .git/hooks/update. My repository is "owned" by gate_keeper. My
> user login is dreiland. I push changes back to the gate_keeper
> repository and stuff under .git gets owned by me. Now, I log as a
> gate_keeper to get a Linus update or perform the internal_testing
> merges and things fail because it is owned by dreiland.
Did you do a git-init-db --shared ?
does gate_keeper and yourself belong to the same group?
--
Alan Chandler
^ permalink raw reply
* Re: Problem with git-apply?
From: Shawn Pearce @ 2006-11-04 7:30 UTC (permalink / raw)
To: Kevin Shanahan; +Cc: git
In-Reply-To: <20061104072349.GA19667@cubit>
Kevin Shanahan <kmshanah@disenchant.net> wrote:
> git apply ../test.diff
Try:
git apply --index ../test.diff
instead. The --index is needed to record the new file in the index;
otherwise it won't actually be added during commit.
--
^ permalink raw reply
* Problem with git-apply?
From: Kevin Shanahan @ 2006-11-04 7:23 UTC (permalink / raw)
To: git
Hi,
I seem to be having problems using git-apply to apply any patch which
creates a new file. Unfortunately it's been a few weeks since I last
used git here locally, but this seems like some behaviour change since
the last version I was using. I'm currently using version 1.4.3.3 from
Debian Sid. This little test script demonstrates the problem I'm
having:
#!/bin/sh
mkdir a b repo
echo foo > b/foo
diff -urN a b > test.diff
(
cd repo
echo bar > bar # need something to init the db
git init-db
git add .
git commit -a -m "Test Commit"
git apply ../test.diff
git commit -a -m "Test Commit (file added)"
)
Here, this outputs for me:
defaulting to local storage area
Committing initial tree ee314a31b622b027c10981acaed7903a3607dbd4
error: foo: No such file or directory
nothing to commit
Has something broken or am I doing something wrong here?
Thanks,
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-04 5:10 UTC (permalink / raw)
To: Jeff King; +Cc: Sean, Karl Hasselstr?m, Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103232936.GC6970@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Nov 03, 2006 at 03:29:45PM -0500, Shawn Pearce wrote:
>
> > Nack. I'd rather see the entries added/removed from .git/config when
> > the branch is created/deleted, just like the ref and the reflog are
> > created/deleted. It makes behavior more consistent for the user
> > and it is mostly self documenting...
>
> If we go this route, please consider updating .git/auto-branch-config or
> similar, and adding the functionality to include that file into
> .git/config.
>
> I think the concept of automagically munging a user-editable config file
> is problematic, especially when users might manage those files with
> version control or other systems.
Most users that I know use repo-config to munge their .git/config
rather than editing it by hand. Though with more data stored in
it for branches and remotes that is probably going to change.
If we go this route I wonder if want to say create a config file
per branch and then use a wildcard include like Apache's httpd.conf
wildcard include, e.g.:
.git/config:
include branch_configs/**/*.config
.git/branch_configs/refs/heads/master.config:
[branch "master"]
...
As then git-branch is only manipulating one file per branch.
--
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-04 5:04 UTC (permalink / raw)
To: Sean; +Cc: Karl Hasselström, Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103162707.cc8af608.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Fri, 3 Nov 2006 15:29:45 -0500
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > Nack. I'd rather see the entries added/removed from .git/config when
> > the branch is created/deleted, just like the ref and the reflog are
> > created/deleted. It makes behavior more consistent for the user
> > and it is mostly self documenting...
> >
> > "why is branch FOO pulling FOO by default? ahhh, its in
> > .git/config after git branch FOO FOO."
> >
> > Same goes for git-clone. The branch.master.merge=origin/master
> > entry should be in .git/config file after the clone is complete.
>
> Well that's certainly an alternative implementation that achieves
> the same thing. The essential point is that most of the time the
> Git user should not have to manually create the merge entries
> in the config file. Git should be smart enough to get it right
> most of the time automatically.
Agreed completely. At least though with repo-config we have a
command line tool which users/scripts alike can use to read/edit
the configuration of a "remote"; .git/remotes/ has no such tool.
--
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-04 5:03 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Miles Bader, git, Karl Hasselström
In-Reply-To: <20061103162422.b0bf105e.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Fri, 3 Nov 2006 15:36:10 -0500
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > > Maybe even going as far as automatically creating a local branch
> > > for each remote branch on clone is worth considering.
> >
> > Nack.
> >
> > I work with a workflow where our central repository has 2 important
> > branches (vmtip and vmvt), and a bunch of transient developer
> > topic branches (e.g. sp/foo). We only have a master branch in this
> > repository so that git-clone will clone it without choking during
> > the clone. Users tend to do immediately after a clone:
> >
> > git branch -D master
> > git branch -D origin
> > git branch -D ... other topic branches not interested in ...
> > edit .git/remotes/origin ... delete topic branches ...
>
> I think your Nack was a little rash here. The feature would be quite
> useful to work flows other than yours. It sounds like what _you_ want
> is a feature to select branches when cloning rather than the current
> default of cloning all. That would stop your developers having to
> delete branches and editing .git/remotes/origin immediately
> after cloning.
After reading your reply you are probably correct. I can see there
may be workflows that want every remote branch also created as a
local branch.
I could certainly live with a command line option to clone, e.g.:
git clone --only vmdvt,vmtip user@host:/path...
So yes, my 'Nack' may have been a little too rash.
--
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jakub Narebski @ 2006-11-04 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611031640140.25218@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sat, 4 Nov 2006, Jakub Narebski wrote:
>>
>> YAUO, Yet Another Undocumented Option. ::sigh::
>
> The "--pretty=xxx" is certainly not new, and it's not even totally
> undocumented. It's mentioned in several of the examples in various forms.
>
> All the logging commands take the "pretty" argument.
>
> Try
>
> git log --pretty={oneline,short,medium,full,fuller,raw}
>
> (and the same things work for "git whatchanged" and "git show" etc)
I meant git show --pretty=email option. Sorry for confusion.
--
Jakub Narebski
^ permalink raw reply
* Re: git-format-patch little gripe
From: Linus Torvalds @ 2006-11-04 0:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eigjql$ql$2@sea.gmane.org>
On Sat, 4 Nov 2006, Jakub Narebski wrote:
>
> YAUO, Yet Another Undocumented Option. ::sigh::
The "--pretty=xxx" is certainly not new, and it's not even totally
undocumented. It's mentioned in several of the examples in various forms.
All the logging commands take the "pretty" argument.
Try
git log --pretty={oneline,short,medium,full,fuller,raw}
(and the same things work for "git whatchanged" and "git show" etc)
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-11-04 0:02 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20061103225041.GQ20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Fri, Nov 03, 2006 at 11:44:48PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Jakub Narebski <jnareb@gmail.com> writes:
>> > Which solution do you think it's best?
>>
>> Sorry, if it was not clear in my message, I wanted to say that I
>> kinda liked those "control pictures" in U+2400 range.
>
> In principle, right now it should be pretty easy for a project that for
> some reason does not use UTF-8 in commits etc. to adjust gitweb to work
> properly, right? Just change the encoding in HTTP headers and you're
> done, I think.
>
> Is it worth trying to preserve that flexibility?
Absolutely, and I got your point. Maybe <blink>\011</blink>
would be more portable and appropriate.
Also munging [:cntrl:] would break iso-2022 encoding if it
munges ESC, but the function under discussion was only for paths
and I think no sane platform would use iso-2022 for filenames.
Each repository has commit charset/encoding configuration item
if I am not mistaken, so it is probably a sane thing to do to
convert commit messages from that uniformly to utf-8, I think.
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jakub Narebski @ 2006-11-03 23:37 UTC (permalink / raw)
To: git
In-Reply-To: <20061103231647.GB6970@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Nov 03, 2006 at 02:35:05PM -0800, Carl Worth wrote:
>
>> I mean, git show is fine for displaying something to just read it, but
>> if the results are to be fed back into git at some point, then
>> git-show is pretty useless, (throws away commit message, author,
>> timestamp, etc.).
>
> Try
> git-show --pretty=email
> or even
> git-show --pretty=email --stat -p
YAUO, Yet Another Undocumented Option. ::sigh::
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-03 23:35 UTC (permalink / raw)
To: git
In-Reply-To: <20061103225041.GQ20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Fri, Nov 03, 2006 at 11:44:48PM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Jakub Narebski <jnareb@gmail.com> writes:
>> > Which solution do you think it's best?
>>
>> Sorry, if it was not clear in my message, I wanted to say that I
>> kinda liked those "control pictures" in U+2400 range.
>
> In principle, right now it should be pretty easy for a project that for
> some reason does not use UTF-8 in commits etc. to adjust gitweb to work
> properly, right? Just change the encoding in HTTP headers and you're
> done, I think.
>
> Is it worth trying to preserve that flexibility?
It should be also quite easy to change to_uft8 subroutine to actually
convert to utf8. But even if we don't use UTF-8 encoding for HTML in
gitweb, numerical character entities (and that's how those "control
pictures" are entered) should work equally well regardless of encoding.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git bug? + question
From: Jeff King @ 2006-11-03 23:29 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Sean, Karl Hasselstr?m, Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103202945.GA7585@spearce.org>
On Fri, Nov 03, 2006 at 03:29:45PM -0500, Shawn Pearce wrote:
> Nack. I'd rather see the entries added/removed from .git/config when
> the branch is created/deleted, just like the ref and the reflog are
> created/deleted. It makes behavior more consistent for the user
> and it is mostly self documenting...
If we go this route, please consider updating .git/auto-branch-config or
similar, and adding the functionality to include that file into
.git/config.
I think the concept of automagically munging a user-editable config file
is problematic, especially when users might manage those files with
version control or other systems.
^ permalink raw reply
* Re: git and "dumb protocols"
From: Daniel Barkalow @ 2006-11-03 23:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq4ptixdfj.fsf@ecrins.imag.fr>
On Thu, 2 Nov 2006, Matthieu Moy wrote:
> I'll probably do, but my concern is broader than that. I like the
> ability to use almost any webhosting service for my revision control.
> GNU Arch was quite good at that, bzr is also (doesn't support webdav
> very well yet, but read-only-HTTP, sftp and ftp are there), so I'd
> like git to do the same.
You should be able to put together the repository you want hosted locally
and use any webhosting service updating procedure to update what's hosted.
AFAIK, git.kernel.org is a completely dumb mirror of master.kernel.org,
working like that.
The main thing is that you want "objects" to be updated before "refs", and
you don't want to do any git operations during the mirroring. But it's not
even that important, so long as whenever you leave the mirror for a while,
it matches some final state (with respect to git) of the master.
What you actually care about the git-native stuff for is preparing the
master image, so that you don't have random cruft from your working
repository, and then you just want it to mirror efficiently.
-Daniel
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jeff King @ 2006-11-03 23:16 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Luben Tuikov, git
In-Reply-To: <87velwupk6.wl%cworth@cworth.org>
On Fri, Nov 03, 2006 at 02:35:05PM -0800, Carl Worth wrote:
> I mean, git show is fine for displaying something to just read it, but
> if the results are to be fed back into git at some point, then
> git-show is pretty useless, (throws away commit message, author,
> timestamp, etc.).
Try
git-show --pretty=email
or even
git-show --pretty=email --stat -p
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Alex Riesen @ 2006-11-03 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7v3b908h88.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Nov 03, 2006 20:25:59 +0100:
> > I wanted to have a visual indication of which branches are
> > local and which are remote in git-branch -a output; however
> > Junio was concerned that someone might be using the output in
> > a script. This patch addresses the problem by colouring the
> > git-branch output - which in "auto" mode won't be activated.
>
> Yuck. We are getting more and more color happy. As long as
> this stays optional I'm Ok with it; we'll see if people find it
> useful soon enough.
>
As long as the output stays stable one can always colorize it with
an external program, using pseudo terminals, if needed. Wont work
for the other platform though. As usual.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Petr Baudis @ 2006-11-03 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vwt6c40bj.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Nov 03, 2006 at 11:44:48PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jakub Narebski <jnareb@gmail.com> writes:
> > Which solution do you think it's best?
>
> Sorry, if it was not clear in my message, I wanted to say that I
> kinda liked those "control pictures" in U+2400 range.
In principle, right now it should be pretty easy for a project that for
some reason does not use UTF-8 in commits etc. to adjust gitweb to work
properly, right? Just change the encoding in HTTP headers and you're
done, I think.
Is it worth trying to preserve that flexibility?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-11-03 22:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611032333.49794.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Well, control characters (at least some of them) are not correct
> characters in UTF-8 HTML output; Mozilla in strict XHTML mode complains.
> Currently...
I said you quote controls (and only controls) as unsafe, so you
are not disagreeing with me here. However "controls are unsafe"
does not necessarily mean "unsafe characters are all controls",
does it? That was what my comments abuot the comment before the
function was.
> Which solution do you think it's best?
Sorry, if it was not clear in my message, I wanted to say that I
kinda liked those "control pictures" in U+2400 range.
^ permalink raw reply
* Re: git-format-patch little gripe
From: Carl Worth @ 2006-11-03 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7v3b905fqi.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Fri, 03 Nov 2006 14:26:29 -0800, Junio C Hamano wrote:
> If you want a single patch, you can always say "git show", by
> the way.
Ugh.
I mean, git show is fine for displaying something to just read it, but
if the results are to be fed back into git at some point, then
git-show is pretty useless, (throws away commit message, author,
timestamp, etc.).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-03 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virhw5hoi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> # quote unsafe characters and escape filename to HTML
>> sub esc_path {
>> my $str = shift;
>> $str = esc_html($str);
>> $str =~ s!([[:cntrl:]])!sprintf('<span
class="cntrl">&#%04d;</span>', 9216+ord($1))!eg;
>> return $str;
>> }
>>
>> with perhaps the following CSS
>>
>> span.cntrl {
>> border: dashed #aaaaaa;
>> border-width: 1px;
>> padding: 0px 2px 0px 2px;
>> margin: 0px 2px 0px 2px;
>> }
>>
>> What do you think of it?
>
> Probably "# quote unsafe characters" is not what it does yet (it
> just quotes controls currently and nothing else), but we have to
> start somewhere and I think this is a good start.
Well, control characters (at least some of them) are not correct
characters in UTF-8 HTML output; Mozilla in strict XHTML mode complains.
Currently for example esc_html escapes FORM FEED (FF) and ESCAPE (ESC)
characters, because they happened to be present in git.git repository
(in COPYING file and in commit v1.4.2.1-g20a3847 respectively).
As I see it, we can either replace non-safe characters (control
characters) by single characters a la --hide-control-chars: that
is minimal solution, or we can quote unseafe characters somewhat,
but if we do that we have to indicate that we quote. Git core and
ls encloses material which needs escaping with quotes; in gitweb
it is somewhat impractical; besides we have more possibilities
to mark fragment of text (span element encompassing representation
of escaped characters for example).
I have thought of the following escaping:
1. Hide control characters using '?' or other similar character like
ċ for example
2. Use "Unicode" quoting, i.e. replace control characters by their
Unicode Printable Representation (PR), as shown above. Has the
advantage that it is simple and does not need theoretically marking
that it is quoted; has the disadvantage that browser must support
this part of Unicode, and that those characters are less than
readable with default font size gitweb uses.
3. Use Character Escape Codes (CEC), using alphabetic and octal
backslash sequences like those used in C. Probably need to escape
backslash (quoting character) too. Has the advantage of being widely
understood in POSIX world. Has the disadvantage of need for escape
sequence table/hash. Has the advantage that it works for all
characters - simple octal backslash sequence if they have no special
escape sequence.
4. Control key Sequence (CS), like the one used in esc_html currently,
replacing control characters by key sequence that produces them,
for example replacing LF with ^J, CR with ^M, FF with ^L, ESC with
^[, TAB with ^I. Has the advantage of being undestodd I think in
MS-DOS/MS WIndows world. Has the advantage of being used in esc_html.
Has the advantage that some text editors use this representation.
Has the disadvantage of need for large key sequence table/hash.
Has the disadvantage that less common control characters have cryptic
control key sequences.
5. Percent encoding, also know as URL encoding. Use %<hex> encoding used
in URL, taken for example from core of esc_url/esc_param subroutine.
Simple, but does need marking that is escaped. Disadvantage of hardly
readable.
Which solution do you think it's best? Or perhaps other solution, like
using Unicode Printable Representation, or Character Escape Codes with
the exception of LF which would be replaced by ¶ (paragraph sign),
RET by ↵ and TAB by either þ, ↦ or →.
--
Jakub Narebski
^ permalink raw reply
* Re: git-format-patch little gripe
From: Junio C Hamano @ 2006-11-03 22:26 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061103195253.9244.qmail@web31814.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Also I doubt how many people actually have coded in their scripts
> "git-format-patch <sha-1>" to mead by default "<sha-1>..HEAD" -- I'd think
> that maintainers always want to know the "end point" and would always
> use the <a>..<b> format, instead of presuming where/what their HEAD is.
Well, the answer would be "do not script around Porcelain".
> Sorry it's my rant. I know it's not your fault.
I do not even think there is any "fault" there, to be honest, so
there is no need to apologize. The format-patch command does
what it was designed to do and does it well -- format a sequence
of patches for upstream submission.
If you want a single patch, you can always say "git show", by
the way.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-11-03 21:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611031719.13073.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> # quote unsafe characters and escape filename to HTML
> sub esc_path {
> my $str = shift;
> $str = esc_html($str);
> $str =~ s!([[:cntrl:]])!sprintf('<span class="cntrl">&#%04d;</span>', 9216+ord($1))!eg;
> return $str;
> }
>
> with perhaps the following CSS
>
> span.cntrl {
> border: dashed #aaaaaa;
> border-width: 1px;
> padding: 0px 2px 0px 2px;
> margin: 0px 2px 0px 2px;
> }
>
> What do you think of it?
Probably "# quote unsafe characters" is not what it does yet (it
just quotes controls currently and nothing else), but we have to
start somewhere and I think this is a good start.
^ permalink raw reply
* Re: git bug? + question
From: Sean @ 2006-11-03 21:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Karl Hasselström, Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103202945.GA7585@spearce.org>
On Fri, 3 Nov 2006 15:29:45 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> Nack. I'd rather see the entries added/removed from .git/config when
> the branch is created/deleted, just like the ref and the reflog are
> created/deleted. It makes behavior more consistent for the user
> and it is mostly self documenting...
>
> "why is branch FOO pulling FOO by default? ahhh, its in
> .git/config after git branch FOO FOO."
>
> Same goes for git-clone. The branch.master.merge=origin/master
> entry should be in .git/config file after the clone is complete.
Well that's certainly an alternative implementation that achieves
the same thing. The essential point is that most of the time the
Git user should not have to manually create the merge entries
in the config file. Git should be smart enough to get it right
most of the time automatically.
^ permalink raw reply
* Re: git bug? + question
From: Sean @ 2006-11-03 21:24 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Miles Bader, git, Karl Hasselström
In-Reply-To: <20061103203610.GB7585@spearce.org>
On Fri, 3 Nov 2006 15:36:10 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> > Maybe even going as far as automatically creating a local branch
> > for each remote branch on clone is worth considering.
>
> Nack.
>
> I work with a workflow where our central repository has 2 important
> branches (vmtip and vmvt), and a bunch of transient developer
> topic branches (e.g. sp/foo). We only have a master branch in this
> repository so that git-clone will clone it without choking during
> the clone. Users tend to do immediately after a clone:
>
> git branch -D master
> git branch -D origin
> git branch -D ... other topic branches not interested in ...
> edit .git/remotes/origin ... delete topic branches ...
I think your Nack was a little rash here. The feature would be quite
useful to work flows other than yours. It sounds like what _you_ want
is a feature to select branches when cloning rather than the current
default of cloning all. That would stop your developers having to
delete branches and editing .git/remotes/origin immediately
after cloning.
^ permalink raw reply
* Re: weird strncmp usage?
From: Florian Weimer @ 2006-11-03 21:05 UTC (permalink / raw)
To: git
In-Reply-To: <45494D84.2060402@shadowen.org>
* Andy Whitcroft:
> If you are doing these a _lot_ then there is a significant additional
> cost to using strlen on a constant string.
strlen has been a GCC builtin for quite some time. If the wrapper
function is inlined, GCC will optimize it away. (It also turns the
^ 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