* [BUG] Gitk elides backslashes in author names
From: Eric Hanchrow @ 2008-10-10 2:51 UTC (permalink / raw)
To: git
Here's how to reproduce the problem with git version 1.6.0.2.415.g9800c0:
$ cd /tmp
$ rm -rf x
$ mkdir x
$ cd x
$ git init
Initialized empty Git repository in /tmp/x/.git/
$ touch it
$ git commit -a --author="back\\slash <foo@bar.com>" -m "yeah"
Created initial commit 0f65eda: yeah
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 it
$ git log
commit 0f65eda51f33f5c56ba61f2c9dc1c5d38baec75c
Author: back\slash <foo@bar.com>
Date: Thu Oct 9 19:42:17 2008 -0700
yeah
$ gitk
Now note that the author appears as "backslash", not "back\slash".
You might wonder why I have backslashes in my author names: it's
because I'm using git-svn, and our Subversion setup -- which uses
Windows authentication -- creates names with backslashes.
--
However lousy it is to sit in your basement and pretend to be an
elf, I can tell you from personal experience it's worse to sit in your
basement and try to figure if Ginger or Mary Ann is cuter.
-- Clay Shirky
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Elijah Newren @ 2008-10-10 4:25 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Caleb Cushing, git, Jeff King,
Junio C Hamano
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>
On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
<snip>
> A few radical suggestions might be:
>
> 1. make ls-files and diff --name-status use compatible letters
>
> 2. rename git commit -n to git commit -b (as in bypass), make git commit
> -n do what's expected ("--dry-run", n as in duNNo yet)
Ouch. Please not -b. I guess I need to get my other suggestions
upstream if I want to avoid option conflicts like this...
> 3. rename git status to git commit -n
>
> 4. make git status generate git diff --name-status like output
I'd really prefer to be able to get staged vs. unstaged information
out of status. And the single-letter output, like what cvs/svn/hg
have, is less descriptive here. (Sure, git status could use some
cleanup IMO, but a word instead of a letter for modification status is
a usability improvement in git over those other systems for new VCS
users.)
> (3+4)'. make git status -l generate git diff --name-status like output
> (l as in status Letter) as an alternative to 3+4
That seems nicer.
And another radical suggestion (wasn't this brought up before too?):
5. Allow limiting the status output to a set of paths. diff, log,
add, grep, etc. can all take a subdirectory name and limit their
operation to files recursively underneath that path, but git status
doesn't do so when you run 'git status DIR'. I know why it currently
behaves as it does, but it sure seems like unnecessary UI
inconsistency.
Just my $0.02,
Elijah
^ permalink raw reply
* Re: [PATCH] fix pread()'s short read in index-pack
From: Alex Riesen @ 2008-10-10 6:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.2.00.0810092140500.26244@xanadu.home>
2008/10/10 Nicolas Pitre <nico@cam.org>:
>
> Since v1.6.0.2~13^2~ the completion of a thin pack uses sha1write() for
> its ability to compute a SHA1 on the written data. This also provides
> data buffering which, along with commit 92392b4a45, will confuse pread()
> whenever an appended object is 1) freed due to memory pressure because
> of the depth-first delta processing, and 2) needed again because it has
> many delta children, and 3) its data is still buffered by sha1write().
So I seem to have had luck not doing gc in either of source or target repos
(I usually repack, than fetch. Especially this one repo, it's very active).
BTW, I run into complications trying to test the fix on Shawn's
master: conflicts,
and my trivial resolution wasn't good enough.
Aside from that, I confirm the case fixed.
^ permalink raw reply
* merge hook
From: Erik Colson @ 2008-10-10 7:21 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 207 bytes --]
Hello,
Is it possible to launch a custom script on all files involved in a
merge to master ?
If yes, is it then also possible to reject the merge if the script
returns an error ?
Thanks
--
Erik
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Management of opendocument (openoffice.org) files in git
From: Peter Krefting @ 2008-10-10 8:12 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <48E4C401.90409@drmicha.warpmail.net>
Michael J Gruber:
> I'm not sure about the lessons, but I wanted to share the numbers
> anyways. I think this (your script and its usage) is heading in a useful
> direction and should maybe made more known, if not made easier from the
> git side.
I had very positive experiences with the script for my use-case. I did
post them to the list, but it seems as if they got lost. At least I
can't seem to find them, did they show up?
I had some problems with the script when trying to run it under
Windows, though. Running Windows-Git from a Cygwin prompt provides some
confusion about some of the Unix tools' behaviour that I needed to
work around (like removing "/cygdrive" prefixes).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Feature Request: Branch Annotations
From: Peter Krefting @ 2008-10-10 8:24 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, David Soria Parra, Rotem Yaari, Git Mailing List
In-Reply-To: <32541b130810081621k32493e20occba9cd97671775d@mail.gmail.com>
Avery Pennarun:
> I guess bash completions would help with this (if you're using bash),
> but even then it's kind of unreasonable to name branches something
> like "bug-111234-widget-performance-improvements-for-customer-x",
> which is the sort of information that would be awfully helpful two
> months later when you're looking at old unmerged branches.
That's exactly what I do for one of the projects I am working on (well,
minus the "bug-" prefix, that's implied). Bash completion works quite
well for that, and the merge commits do give meaningful information.
But I would still like to be able to annotate it. Especially for
long-living bug-fix branches, it could be useful to be able to add
describe a branch with what state it is in, for instance.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCHv2] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-10 8:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce, Petr Baudis
In-Reply-To: <1223457985-27094-1-git-send-email-giuseppe.bilotta@gmail.com>
On Wed, 8 Oct 2008, Giuseppe Bilotta wrote:
> Since input parameters can be obtained both from CGI parameters and
> PATH_INFO, we would like most of the code to be agnostic about the way
> parameters were retrieved. We thus collect all the parameters into the
> new %input_params hash, delaying validation after the collection is
> completed.
>
> Although the kludge removal is minimal at the moment, it makes life much
> easier for future expansions such as more extensive PATH_INFO use or
> other form of input such as command-line support.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Very nice.
Acked-by: Jakub Narebski <jnareb@gmail.com>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-10 8:56 UTC (permalink / raw)
To: git@vger.kernel.org >> Git Mailing List; +Cc: Michael J Gruber
In-Reply-To: <48EE132E.1040407@drmicha.warpmail.net>
Michael J Gruber wrote:
> Knut Eldhuset venit, vidit, dixit 08.10.2008 11:20:
>> Michael J Gruber wrote:
>>> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
<snip>
>>> So, in order to help you, we would need to know
>>>
>>> - the layout of your svn repo: where are trunk, branches and tags, how
>>> did you create branches and tags in svn, are "projects" entirely separate
>> https://server/trunk
>> https://server/branches
>> https://server/tags
>>
>> We really only have one "project" source tree at
>> https://server/trunk/some_folder/project/src
>>
>> However, once the sources were at
>> https://server/trunk/some_folder/project/old_source
>
> That may be the source of the trouble. In fact, the log below indicates
> that it is more like the following two paths:
>
> https://server/trunk/project/old_source
> https://server/trunk/project/src/client
>
I think my description is correct, but these particular log messages may
not be the best examples. We did have files and folders in "old_source"
that moved to "src".
>> Therefore we have the following:
>>
>> $ svn log -v -r4871 https://server/
>> ------------------------------------------------------------------------
>> r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>> D /trunk/project/old_source/some_file
>> A /trunk/project/src/client/some_file (from
>> /trunk/project/old_source/some_file:4795)
>>
>> commit-message
>> ------------------------------------------------------------------------
>>
>> $ svn log -v -r4869 https://server/
>> ------------------------------------------------------------------------
>> r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>> A /trunk/project/src
>> A /trunk/project/src/client
>>
>> commit-message
>>
>> ------------------------------------------------------------------------
>>
>> $ svn log -v -r4868 https://server/
>> ------------------------------------------------------------------------
>> r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>>
>> commit-message
>>
>
> That one is funny. A modified directory but no paths modified
> underneath. Was this a propset?
>
These give identical output:
svn log -v -r4868 --xml https://server
and
svn log -v -r4868 --with-all-revprops --xml https://server
I don't understand what happened there. It was a commit made with svk,
so maybe that had something to do with it.
>> ------------------------------------------------------------------------
>>
>> $ svn log -v -r4867 https://server/
>> ------------------------------------------------------------------------
>> r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
>> Changed paths:
>> M /trunk/project
>> A /trunk/project/some_file
>>
>> commit-message
>> ------------------------------------------------------------------------
>
> Maybe you're trying too hard to disguise things. Are you really adding
> some_file right under project here and under project/src/client in r4871?
>
No, those were different files... I'm sorry I can't share the repo publicly.
>> r4868 appears twice in git. One commit is on master/trunk and has parent
>> and child, while the other is on a branch and has no parent.
>>
>>> - your incarnation of git-svn
>>>
>> # git --version
>> git version 1.6.0.2
>
> I actually meant incantation, I guess I should brush up on my little
> latin, uhm ;)
>
> So, did you use something like
>
> git svn init -s https://server/
>
> or
>
> git svn init -T trunk/project/src/client -t 'tags/*/project/src/client'
> -b 'branches/*/project/src/client' https://server/
>
I used
git svn clone -s https://server/
initially. Then I tried
git svn clone -T trunk/project/src -r tags -b branches https://server/
which gave better results. Then I settled on using "-r4869:HEAD".
> My suggestion would to use two svn sections (option "-R") with different
> configs for different repo structures, and to fetch the first one with
> "-r1:4866" and the second one with "-r4871:HEAD". Reorganising the svn
> repo layout can confuse git-svn quite a bit (and understandably so).
> Using different configs for different "epochs" helps. grafts are your
> friend when it comes to connecting the two.
>
> Michael
Good suggestion. I didn't realize one could do it that way.
Regards,
Knut
^ permalink raw reply
* Re: tip tree clone fail
From: Wang Chen @ 2008-10-10 8:57 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo Molnar, FNST-Lai Jiangshan, FJ-KOSAKI Motohiro,
H. Peter Anvin, git, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810101046260.3271@apollo>
Thomas Gleixner said the following on 2008-10-10 16:56:
> On Fri, 10 Oct 2008, Wang Chen wrote:
>> Thomas Gleixner said the following on 2008-10-10 16:40:
>>> On Fri, 10 Oct 2008, Ingo Molnar wrote:
>>>
>>>> Cc:-ed Thomas too - Thomas just ran a clean git clone and that succeeded
>>>> for him, both over the http and over the git protocols.
>>> No, I did ssh and git. Will start a http one now.
>> OK. I will wait.
>> Thanks, Thomas :)
>
> git clone http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
>
> fails here as well.
>
> Getting pack 7c461fa5d92f9e047ae07b70eb30828a63a803f5
> which contains 874e848aefc2d5952b00593c9fd23d748259eec7
> walk 874e848aefc2d5952b00593c9fd23d748259eec7
> Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/
> error: Unable to find 85ba94ba0592296053f7f2846812173424afe1cb under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
> Cannot obtain needed object 85ba94ba0592296053f7f2846812173424afe1cb
> while processing commit 874e848aefc2d5952b00593c9fd23d748259eec7.
> fatal: Fetch failed.
>
> The needed object 85ba94ba0592296053f7f2846812173424afe1cb is a commit
> in linus tree.
>
> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
> 1.5.3.x)
>
My git version is 1.5.5.1, although it doesn't matter ;)
> Junio, can you please have a look ? I know it's http again, but we can
> not sanitze the corporate firewall folks by any means.
>
^ permalink raw reply
* Re: tip tree clone fail
From: Thomas Gleixner @ 2008-10-10 8:56 UTC (permalink / raw)
To: Wang Chen
Cc: Ingo Molnar, FNST-Lai Jiangshan, FJ-KOSAKI Motohiro,
H. Peter Anvin, git, Junio C Hamano
In-Reply-To: <48EF14FC.1000801@cn.fujitsu.com>
On Fri, 10 Oct 2008, Wang Chen wrote:
> Thomas Gleixner said the following on 2008-10-10 16:40:
> > On Fri, 10 Oct 2008, Ingo Molnar wrote:
> >
> >> Cc:-ed Thomas too - Thomas just ran a clean git clone and that succeeded
> >> for him, both over the http and over the git protocols.
> >
> > No, I did ssh and git. Will start a http one now.
>
> OK. I will wait.
> Thanks, Thomas :)
git clone http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
fails here as well.
Getting pack 7c461fa5d92f9e047ae07b70eb30828a63a803f5
which contains 874e848aefc2d5952b00593c9fd23d748259eec7
walk 874e848aefc2d5952b00593c9fd23d748259eec7
Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
Getting pack list for http://www.kernel.org/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/
error: Unable to find 85ba94ba0592296053f7f2846812173424afe1cb under http://www.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
Cannot obtain needed object 85ba94ba0592296053f7f2846812173424afe1cb
while processing commit 874e848aefc2d5952b00593c9fd23d748259eec7.
fatal: Fetch failed.
The needed object 85ba94ba0592296053f7f2846812173424afe1cb is a commit
in linus tree.
So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
1.5.3.x)
Junio, can you please have a look ? I know it's http again, but we can
not sanitze the corporate firewall folks by any means.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] test-lib: fix color reset in say_color()
From: Jakub Narebski @ 2008-10-10 9:30 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1223590030-7464-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> When executing a single test with colors enabled, the cursor was not set
> back to the previous one, and you had to hit an extra enter to get it
> back.
>
> Work around this problem by calling 'tput sgr0' before printing the
> final newline.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> Actually I'm not 100% sure about how many users are affected. I have a
> black background in konsole with white letters, and after the test I get
> a green cursor, and once I hit enter, I get the white one back.
I also had this very minor irritation that cursor retained color
of last line till enter (or IIRC any key which moved cursor). I use
ordinary xterm from X.Org 6.8.2(213).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Really remove a file ?
From: marcreddist @ 2008-10-10 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <d4bc1a2a0810091643u3903a1f4h44d3579b98fe6922@mail.gmail.com>
Hi,
Thank you both, that's exactly what i needed.
In case someone finds this post in the future, this :
> $ git filter-branch --index-filter 'git update-index --remove
' --force -- --all
worked perfectly. Although, it told me that git can't work on a dirty
directory so I did this :
$ git add .
$ git commit
And after the filter-branch
$ git reset --hard HEAD^
> You'll probably also want to run "git gc" on your repo to
> actually get rid of the huge object that was added (or does
> filter-branch do this automatically?).
I'm not sure it's required by git-filter-branch alone. In this case :
git-gc saves almost 5% after the file deletion
it saves 4.5% before the file deletion
If I run git gc before and after the git filter-branch, it saves 4.5%
and then 0.2%.
But maybe my tests applies to my particular environment and cannot be
generalized.
Thank you again for the help.
Take care,
Marc, happy git user.
--
^ permalink raw reply
* Re: merge hook
From: Johannes Schindelin @ 2008-10-10 10:07 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <20081010072148.GB303@Mac2.local>
Hi,
On Fri, 10 Oct 2008, Erik Colson wrote:
> Is it possible to launch a custom script on all files involved in a
> merge to master ? If yes, is it then also possible to reject the merge
> if the script returns an error ?
>From Documentation/githooks.txt:
-- snip --
prepare-commit-msg
------------------
This hook is invoked by 'git-commit' right after preparing the
default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file that
the commit log message. The second is the source of the commit message,
and can be: [...] `merge` (if the commit is a merge or a `.git/MERGE_MSG`
file exists); [...]
If the exit status is non-zero, 'git-commit' will abort.
-- snap --
To see which files are affected, you'd just need to ask "git diff
--name-only --cached".
I guess that you want to disallow merging in changes from people who
changed files that are none of their business? If so, it would be nice to
contribute the hook as a patch to contrib/.
Ciao,
Dscho
^ permalink raw reply
* Re: merge hook
From: Erik Colson @ 2008-10-10 10:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810101204540.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
On Fri, Oct 10, 2008 at 12:07:16PM +0200, Johannes Schindelin wrote:
[..]
> From Documentation/githooks.txt:
thank you for pointing me there
[..]
> I guess that you want to disallow merging in changes from people who
> changed files that are none of their business? If so, it would be nice to
> contribute the hook as a patch to contrib/.
wrong guess ;)
The purpose is to check if source code still has debug code in
it. Our policy is to have it removed before reaching master, but
checking by hand is way too buggy ;)
--
erik
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
From: Paul Mackerras @ 2008-10-10 10:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alexander Gavrilov, git, Shawn O. Pearce
In-Reply-To: <48E36086.7050504@viscovery.net>
Johannes Sixt writes:
> I'm about to add a .gitattributes file that specifies the encoding for
> some of my files *today* because I was not clever enough to anticipate the
> usefulness of an "encoding" attribute a year ago when those files were
> added to the repository. When I browse history, I *do* want that *today's*
> encoding is picked.
Fair enough.
> > (Also it seems that we won't
> > notice if the user changes .gitattributes after we've looked at it, or
> > if they create one after we've looked for one and not found it.)
>
> This is not a show stopper, IMHO. The user will notice soon enough, and
> can restart gitk. Nobody sane will change the encoding attributes every hour.
The scenario I'm thinking of is this: a user clicks on a file to
display it, sees that it isn't displayed using the encoding he wants,
says "duh" and creates a .gitattributes file. User clicks on the file
again, sees that it *still* isn't displayed using the right encoding,
and says something worse than "duh". :)
If it was just one .gitattributes file, then it wouldn't be hard to
stat it each time we go to display some file, and throw away our cache
if it has changed. But it looks like we would have to do N+1 stats
for a file N levels deep in the tree (since it looks like we also need
to stat $GIT_DIR/info/attributes). Still, it may be worth it. At
least on Linux, stat is pretty fast.
Paul.
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Johannes Schindelin @ 2008-10-10 11:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Caleb Cushing, git, Jeff King, Junio C Hamano
In-Reply-To: <48EE1F58.2060707@drmicha.warpmail.net>
Hi,
On Thu, 9 Oct 2008, Michael J Gruber wrote:
> 1. make ls-files and diff --name-status use compatible letters
ls-files and diff (at least partially) are plumbing. Breaking backwards
compatibility in these is out of the question.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (GITK) v2 3/4] gitk: Support filenames in the locale encoding.
From: Paul Mackerras @ 2008-10-10 11:23 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <18671.15020.13951.943822@cargo.ozlabs.ibm.com>
I wrote:
> > @@ -6250,11 +6250,12 @@ proc gettreeline {gtf id} {
> > set line [string range $line 0 [expr {$i-1}]]
> > if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
> > set sha1 [lindex $line 2]
> > - if {[string index $fname 0] eq "\""} {
> > - set fname [lindex $fname 0]
> > - }
> > lappend treeidlist($id) $sha1
> > }
> > + if {[string index $fname 0] eq "\""} {
> > + set fname [lindex $fname 0]
> > + }
>
> Concerning this part of the change, do we know whether git ls-files
> will quote filenames containing special characters or not?
A little experiment has convinced me that it does. So this part looks
OK.
Paul.
^ permalink raw reply
* Re: [PATCH (GITK) v2 3/4] gitk: Support filenames in the locale encoding.
From: Paul Mackerras @ 2008-10-10 11:21 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1222772422-28020-4-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> The previous patch changed the encoding used for
> reading diffs to binary, which broke non-ASCII filename
> support. This one fixes the breakage, together with some
> existing bugs related to filename encoding.
Sounds like this patch should be combined with the previous one.
> @@ -6250,11 +6250,12 @@ proc gettreeline {gtf id} {
> set line [string range $line 0 [expr {$i-1}]]
> if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
> set sha1 [lindex $line 2]
> - if {[string index $fname 0] eq "\""} {
> - set fname [lindex $fname 0]
> - }
> lappend treeidlist($id) $sha1
> }
> + if {[string index $fname 0] eq "\""} {
> + set fname [lindex $fname 0]
> + }
Concerning this part of the change, do we know whether git ls-files
will quote filenames containing special characters or not?
Paul.
^ permalink raw reply
* Re: Different behaviour of rebase -i
From: Johannes Schindelin @ 2008-10-10 11:40 UTC (permalink / raw)
To: Leonardo Sobral Cunha; +Cc: git
In-Reply-To: <6beb92080810091204n6df4338fs3b182194a8d6454e@mail.gmail.com>
Hi,
On Thu, 9 Oct 2008, Leonardo Sobral Cunha wrote:
> While doing a git rebase with my upstream branch ahead of my local
> branch, first git rewinds my local branch to point to the upstream and
> then prints "Nothing to do". As expected, my local branch ends pointing
> to the upstream head.
>
> But when I use the same command with the same branches using git rebase
> -i, nothing happens and my local branch does not point to upstream (the
> behaviour is different).
>
> Is this different behaviour of rebase -i expected or is this a bug? This
> is still happening in git version 1.6.0.2.443.g52e83
This is by design. You need to have a way to stop rebasing in the editor.
For example when you realize that you passed the wrong upstream or
something.
The most intuitive way (I thought) is to behave the same as "git commit":
if you do not want to continue, just delete everything.
Now, I can see that it is unconvenient.
A workaround would be to add a line "bla" and when rebase complains about
the unknown command, continue with "git rebase --skip".
Maybe we should add a new command "noop" which is automatically inserted
when there is no other command?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] rebase -i: do not fail when there is no commit to cherry-pick
From: Johannes Schindelin @ 2008-10-10 11:42 UTC (permalink / raw)
To: Leonardo Sobral Cunha, gitster; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810101319150.22125@pacific.mpi-cbg.de.mpi-cbg.de>
In case there is no commit to apply (for example because you rebase to
upstream and all your local patches have been applied there), do not
fail. The non-interactive rebase already behaves that way.
Do this by introducing a new command, "noop", which is substituted for
an empty commit list, so that deleting the commit list can still abort
as before.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Fri, 10 Oct 2008, Johannes Schindelin wrote:
> Maybe we should add a new command "noop" which is automatically
> inserted when there is no other command?
And this implements that.
git-rebase--interactive.sh | 3 ++-
t/t3404-rebase-interactive.sh | 11 +++++++++++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 076414a..49a6b5c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -271,7 +271,7 @@ do_next () {
"$DOTEST"/amend || exit
read command sha1 rest < "$TODO"
case "$command" in
- '#'*|'')
+ '#'*|''|noop)
mark_action_done
;;
pick|p)
@@ -583,6 +583,7 @@ first and then run 'git rebase --continue' again."
--abbrev=7 --reverse --left-right --cherry-pick \
$UPSTREAM...$HEAD | \
sed -n "s/^>/pick /p" > "$TODO"
+ test -s "$TODO" || echo noop >> "$TODO"
cat >> "$TODO" << EOF
# Rebase $SHORTUPSTREAM..$SHORTHEAD onto $SHORTONTO
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e0ded19..7d10a27 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -419,4 +419,15 @@ test_expect_success 'rebase with a file named HEAD in worktree' '
'
+test_expect_success 'do "noop" when there is nothing to cherry-pick' '
+
+ git checkout -b branch4 HEAD &&
+ GIT_EDITOR=: git commit --amend \
+ --author="Somebody else <somebody@else.com>"
+ test $(git rev-parse branch3) != $(git rev-parse branch4) &&
+ git rebase -i branch3 &&
+ test $(git rev-parse branch3) = $(git rev-parse branch4)
+
+'
+
test_done
--
1.6.0.2.713.g3dcb0
^ permalink raw reply related
* Re: [PATCH (GITK) v2 4/4] gitk: Implement batch lookup and caching of encoding attrs.
From: Paul Mackerras @ 2008-10-10 11:48 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1222772422-28020-5-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> When the diff contains thousands of files, calling git-check-attr
> once per file is very slow. With this patch gitk does attribute
> lookup in batches of 30 files while reading the diff file list,
> which leads to a very noticeable speedup.
Why only 30 at a time? The logic would be simpler if cache_gitattr
just did all the paths in one call to git check-attr, and it should be
able to cope with 1000 paths in one call, I would think, which is the
most that gettreediffline will give it.
Also, I wonder why we now have two levels of caching of the encoding
attribute. Your patch 1/4 introduced path_encoding_cache, which was
fine, but now we have path_attr_cache as well, which seems to me to
serve exactly the same function since the encoding is the only
attribute we ever ask about. Surely we don't need both caches?
Even with this batching, I am a bit concerned that adding the encoding
support might make things noticeably slower for people who don't need
any encoding support (which would be the majority, I think). We may
end up needing an option to turn off the checking of the encoding
attribute.
Paul.
^ permalink raw reply
* Re: [PATCH (GITK) v2 4/4] gitk: Implement batch lookup and caching of encoding attrs.
From: Alexander Gavrilov @ 2008-10-10 12:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Johannes Sixt
In-Reply-To: <18671.16658.667581.499095@cargo.ozlabs.ibm.com>
On Fri, Oct 10, 2008 at 3:48 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> When the diff contains thousands of files, calling git-check-attr
>> once per file is very slow. With this patch gitk does attribute
>> lookup in batches of 30 files while reading the diff file list,
>> which leads to a very noticeable speedup.
>
> Why only 30 at a time? The logic would be simpler if cache_gitattr
> just did all the paths in one call to git check-attr, and it should be
> able to cope with 1000 paths in one call, I would think, which is the
> most that gettreediffline will give it.
OS-enforced command-line size limit on Windows is 32K. Cramming in
1000 paths would leave only 32 characters for each path.
> Also, I wonder why we now have two levels of caching of the encoding
> attribute. Your patch 1/4 introduced path_encoding_cache, which was
> fine, but now we have path_attr_cache as well, which seems to me to
> serve exactly the same function since the encoding is the only
> attribute we ever ask about. Surely we don't need both caches?
If the (git-gui) patch that reimplements the tcl_encoding procedure is
applied, we may drop the path_encoding_cache. Current implementation
is too slow for batch lookup, especially if the encoding is actually
not supported, and without the cache the lookup would be done on every
loading of a diff.
> Even with this batching, I am a bit concerned that adding the encoding
> support might make things noticeably slower for people who don't need
> any encoding support (which would be the majority, I think). We may
> end up needing an option to turn off the checking of the encoding
> attribute.
I hope that most diffs don't contain thousands of files at once. And
actual huge diffs are likely to be relatively slow to load anyway.
Alexander
^ permalink raw reply
* Re: merge hook
From: Johannes Schindelin @ 2008-10-10 12:30 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <20081010102603.GC303@Mac2.local>
Hi,
On Fri, 10 Oct 2008, Erik Colson wrote:
> On Fri, Oct 10, 2008 at 12:07:16PM +0200, Johannes Schindelin wrote:
>
> > I guess that you want to disallow merging in changes from people who
> > changed files that are none of their business? If so, it would be
> > nice to contribute the hook as a patch to contrib/.
>
> wrong guess ;) The purpose is to check if source code still has debug
> code in it. Our policy is to have it removed before reaching master, but
> checking by hand is way too buggy ;)
Heh. Still, if it is not too specific, would be nice to have it in
contrib/. So I can point other people to it ;-)
Ciao,
Dscho
^ permalink raw reply
* Git User's Survey 2008 - last call!
From: Jakub Narebski @ 2008-10-10 12:39 UTC (permalink / raw)
To: git
It is now last day of Git User's Survey 2008. So if you didn't submit
your replies, please do it now at
http://tinyurl.com/GitSurvey2008
http://www.survs.com/survey?id=M3PIVU72&channel=2WXE4BVTW8
Thanks in advance
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-daemon: Worked around uclibc buffer problem
From: Lars Stoltenow @ 2008-10-10 13:33 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0810092010370.26244@xanadu.home>
On Thu, Oct 09, 2008 at 08:16:03PM -0400, Nicolas Pitre wrote:
> What is your client version? From v1.6.0.2 and later (with commit
> 6b9c42b4da) this shouldn't matter as things are properly handled on the
> receiving end.
Yah, looks good. I did test it with 1.6.0.1 and some 1.5.* versions on
the client side only. With 1.6.0.2, it works with the unfixed daemon too.
^ 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