* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Sverre Rabbelier @ 2009-12-13 20:56 UTC (permalink / raw)
To: Laszlo Papp; +Cc: Paul Mackerras, Laszlo Papp, git
In-Reply-To: <a362e8010912131030v4c1ef231r7246d7291f6a5677@mail.gmail.com>
Heya,
On Sun, Dec 13, 2009 at 19:30, Laszlo Papp <djszapi@archlinux.us> wrote:
> This is the x. time (6. ?) when I try to get answer, can I count any
> answer after more months ?
As Stephan mentioned, I've also seen only one "Up!" post. Also, I've
seen Paul drop patches before, not on purpose, but probably due to
lack of time to closely track the mailing list. Your best bet is
probably to poke him every so many weeks (two or three). Also, since
there was a question about the existence of a [PATCH 1/2], you could
probably resend just this patch as "[PATCH] Add gitk-git Hungarian
translation" to avoid confusion.
Good luck!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* strange error while pushing
From: Erik Faye-Lund @ 2009-12-13 22:41 UTC (permalink / raw)
To: Git Mailing List
I was going to push some stuff I'm working on to my repo at
repo.or.cz, and just got the following error:
$ GIT_TRACE=1 git push kusma work/daemon-win32:work/daemon-win32-process
trace: built-in: git 'push' 'kusma'
'work/daemon-win32:work/daemon-win32-process'
trace: run_command: 'ssh' 'repo.or.cz' 'git-receive-pack
'\''/srv/git/git/kusma.git'\'''
trace: run_command: 'pack-objects' '--all-progress-implied' '--revs'
'--stdout' '--thin'
trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs'
'--stdout' '--thin'
usage: git pack-objects [{ -q | --progress | --all-progress }]
[--max-pack-size=N] [--local] [--incremental]
[--window=N] [--window-memory=N] [--depth=N]
[--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
[--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
[--stdout | base-name] [--include-tag]
[--keep-unreachable | --unpack-unreachable]
[<ref-list | <object-list]
error: pack-objects died with strange error
error: failed to push some refs to 'ssh://repo.or.cz/srv/git/git/kusma.git'
$ git --version
git version 1.6.6.rc2.5.g49666
Is this something anyone have experienced before?
I'm not entirely sure if this happens on the local side or the remote
side... I've tried with a few different versions locally but the issue
seems to persist, so I'm starting to suspect it's an issue at the
remote end. Any insight, anyone?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: David Kågedal @ 2009-12-13 22:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Michael S. Tsirkin
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
>> Add --revisions flag to rebase, so that it can be used
>> to apply an arbitrary range of commits on top
>> of a current branch.
>
> I would suggest calling the option to invoke that hidden mode not
> "--revisions", but "--reverse" or "--opposite" or something of that
> nature, though. It makes "rebase" work in different direction.
And there are no "revisions" in git. So using that term for anything
would only be confusing. Git has "commits" and various kinds of
references to them.
--
David Kågedal
^ permalink raw reply
* git --version wrong
From: oshybrid @ 2009-12-13 22:51 UTC (permalink / raw)
To: git
After i Instal 1.6.5.5 my "git --version" still shows 1.6.0.5
Snow Leopard
Model Name: MacBook Pro
Model Identifier: MacBookPro1,1
Processor Name: Intel Core Duo
Processor Speed: 2.16 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 2 MB
Memory: 2 GB
Bus Speed: 667 MHz
Boot ROM Version: MBP11.0055.B08
SMC Version (system): 1.2f10
Serial Number (system): W86162J5VWX
Hardware UUID: 00000000-0000-1000-8000-0016CB94B85F
Sudden Motion Sensor:
State: Enabled
--
View this message in context: http://old.nabble.com/git---version-wrong-tp26770625p26770625.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: strange error while pushing
From: Erik Faye-Lund @ 2009-12-13 22:57 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <40aa078e0912131441i370d9c23r65c42fe1f46bd194@mail.gmail.com>
On Sun, Dec 13, 2009 at 11:41 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> I'm not entirely sure if this happens on the local side or the remote
> side... I've tried with a few different versions locally but the issue
> seems to persist, so I'm starting to suspect it's an issue at the
> remote end. Any insight, anyone?
Pushing to github gives the same error, so I guess it's a local thing.
I'll check some older versions.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: strange error while pushing
From: Jeff King @ 2009-12-13 23:02 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0912131441i370d9c23r65c42fe1f46bd194@mail.gmail.com>
On Sun, Dec 13, 2009 at 11:41:49PM +0100, Erik Faye-Lund wrote:
> I was going to push some stuff I'm working on to my repo at
> repo.or.cz, and just got the following error:
>
> $ GIT_TRACE=1 git push kusma work/daemon-win32:work/daemon-win32-process
> trace: built-in: git 'push' 'kusma'
> 'work/daemon-win32:work/daemon-win32-process'
> trace: run_command: 'ssh' 'repo.or.cz' 'git-receive-pack
> '\''/srv/git/git/kusma.git'\'''
> trace: run_command: 'pack-objects' '--all-progress-implied' '--revs'
> '--stdout' '--thin'
> trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs'
> '--stdout' '--thin'
I notice your pack-objects is being called with the new
--all-progress-implied, and then you get a usage error with
pack-objects:
> usage: git pack-objects [{ -q | --progress | --all-progress }]
> [--max-pack-size=N] [--local] [--incremental]
> [--window=N] [--window-memory=N] [--depth=N]
> [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
> [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
> [--stdout | base-name] [--include-tag]
> [--keep-unreachable | --unpack-unreachable]
> [<ref-list | <object-list]
Is it possible you have a new git accidentally calling an old version of
pack-objects?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Paul Mackerras @ 2009-12-13 23:03 UTC (permalink / raw)
To: Laszlo Papp; +Cc: Laszlo Papp, git
In-Reply-To: <a362e8010912131030v4c1ef231r7246d7291f6a5677@mail.gmail.com>
On Sun, Dec 13, 2009 at 07:30:21PM +0100, Laszlo Papp wrote:
> This is the x. time (6. ?) when I try to get answer, can I count any
> answer after more months ? What happens here, what's the reason for it
> not be answered ? It's a new translation that could help git project,
> Why didn't I get any response ? But if this is the general situation I
> need to ignore my dream to contribute more in git project... :(
Actually, I thought I had put it in. In any case, a gentle reminder
would suffice, you don't have to whinge about it. Re-posting the
patch cleanly with a nice clear stand-alone patch description (without
distractions such as unnecessary "Re:" or incorrect "[PATCH 2/2]" in
the subject) is very helpful and is probably the best way to get your
patch noticed.
In any case, your patch has problems: I applied it and then ran
make to update the message catalogs, and I got these errors:
Generating catalog po/hu.msg
msgfmt --statistics --tcl po/hu.po -l hu -d po/
po/hu.po:41: end-of-line within string
po/hu.po:41:4: syntax error
po/hu.po:42: end-of-line within string
po/hu.po:666: end-of-line within string
po/hu.po:666:10: syntax error
po/hu.po:667: end-of-line within string
msgfmt: found 6 fatal errors
make: *** [po/hu.msg] Error 1
so I reverted it.
Paul.
^ permalink raw reply
* Re: strange error while pushing
From: Erik Faye-Lund @ 2009-12-13 23:08 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20091213230214.GA27365@sigill.intra.peff.net>
On Mon, Dec 14, 2009 at 12:02 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Dec 13, 2009 at 11:41:49PM +0100, Erik Faye-Lund wrote:
>> usage: git pack-objects [{ -q | --progress | --all-progress }]
>> [--max-pack-size=N] [--local] [--incremental]
>> [--window=N] [--window-memory=N] [--depth=N]
>> [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
>> [--threads=N] [--non-empty] [--revs [--unpacked | --all]*] [--reflog]
>> [--stdout | base-name] [--include-tag]
>> [--keep-unreachable | --unpack-unreachable]
>> [<ref-list | <object-list]
>
> Is it possible you have a new git accidentally calling an old version of
> pack-objects?
>
Ah, yes it is! I just now tracked down the issue myself, and landed at
the same conclution. The reason? Simple, I was pushing git from a
directory with a recent git-binary, when my *installed* git was v1.6.4
;)
Running "make install" before pushing fixed the issue.
Thanks for wasting time on my PEBCAK :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH RESEND] gitk: add "--no-replace-objects" option
From: Paul Mackerras @ 2009-12-13 23:09 UTC (permalink / raw)
To: Christian Couder
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Junio C Hamano
In-Reply-To: <20091212045240.4249.66874.chriscool@tuxfamily.org>
On Sat, Dec 12, 2009 at 05:52:39AM +0100, Christian Couder wrote:
> Replace refs are useful to change some git objects after they
> have started to be shared between different repositories. One
> might want to ignore them to see the original state, and
> "--no-replace-objects" option can be used from the command
> line to do so.
>
> This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> variable, and that is enough to make gitk ignore replace refs.
>
> The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> safer on some platforms, thanks to Johannes Sixt and Michael J
> Gruber.
>
> Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Sverre Rabbelier @ 2009-12-13 23:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Laszlo Papp, Laszlo Papp, git
In-Reply-To: <20091213230305.GA8135@brick.ozlabs.ibm.com>
Heya,
On Mon, Dec 14, 2009 at 00:03, Paul Mackerras <paulus@samba.org> wrote:
> Actually, I thought I had put it in.
> In any case, your patch has problems
> so I reverted it.
Could it be that was what happened before, and as such you thought you
had put it in (which you did), but you forgot that you took it out
and/or forgot to notify Laszlo that it had problems?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: strange error while pushing
From: Sverre Rabbelier @ 2009-12-14 0:01 UTC (permalink / raw)
To: kusmabite; +Cc: Jeff King, Git Mailing List
In-Reply-To: <40aa078e0912131508y79815bej6290c0848aa9f9cf@mail.gmail.com>
Heya,
On Mon, Dec 14, 2009 at 00:08, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> Simple, I was pushing git from a
> directory with a recent git-binary, when my *installed* git was v1.6.4
Isn't this the reason most people don't have "." in their PATH? :P
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Paul Mackerras @ 2009-12-14 1:54 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Laszlo Papp, Laszlo Papp, git
In-Reply-To: <fabb9a1e0912131559p1222a862o33d08b4c5766c866@mail.gmail.com>
On Mon, Dec 14, 2009 at 12:59:08AM +0100, Sverre Rabbelier wrote:
> On Mon, Dec 14, 2009 at 00:03, Paul Mackerras <paulus@samba.org> wrote:
> > Actually, I thought I had put it in.
>
> > In any case, your patch has problems
>
> > so I reverted it.
>
> Could it be that was what happened before, and as such you thought you
> had put it in (which you did), but you forgot that you took it out
> and/or forgot to notify Laszlo that it had problems?
Yes, quite possibly.
Paul.
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Junio C Hamano @ 2009-12-14 2:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091212222046.GA25973@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:
>
>> This is a sane thing to do, as "slot" is part of the name of the variable,
>> and we generally do not warn upon seeing a misspelled variable name (it
>> makes it worse that "func" is not even misspelled but merely unknown to
>> older version of git in your scenario).
>>
>> On the other hand, I suspect that most people would apprecfiate if their
>> git pointed out "diff.color.finc? What do you mean?" before they waste
>> 30 minutes wondering why the new feature in 1.6.6 does not work for them.
>
> I would be more sympathetic to that user if this weren't the _only_ set
> of variables with this property. They don't get warned for diff.externel
> or color.show-branch.
True and fair enough. Let's have this in 1.6.6 then.
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Junio C Hamano @ 2009-12-14 2:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Laszlo Papp, Laszlo Papp, git
In-Reply-To: <20091213230305.GA8135@brick.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> In any case, your patch has problems: I applied it and then ran
> make to update the message catalogs, and I got these errors:
>
> Generating catalog po/hu.msg
> msgfmt --statistics --tcl po/hu.po -l hu -d po/
> po/hu.po:41: end-of-line within string
> po/hu.po:41:4: syntax error
> po/hu.po:42: end-of-line within string
> po/hu.po:666: end-of-line within string
> po/hu.po:666:10: syntax error
> po/hu.po:667: end-of-line within string
> msgfmt: found 6 fatal errors
> make: *** [po/hu.msg] Error 1
>
> so I reverted it.
Syntactically there seem to be only two line-wrapping caused by MUA on the
originating side that caused this. Munging the problematic lines seems to
fix the above.
Now, I don't read _any_ Hungarian, so it could very well be that my fix-up
is wrong and there shouldn't be any SP between two words in 'fájlon belül'
and 'még nincsenek'; if we hear from some Hungarian capable readers that the
fix-up below makes sense, perhaps squashing it in would be the easiest way
to move forward?
diff --git b/gitk-git/po/hu.po a/gitk-git/po/hu.po
index d281e3c..cbaa93d 100755
--- b/gitk-git/po/hu.po
+++ a/gitk-git/po/hu.po
@@ -37,8 +37,7 @@ msgid ""
"No files selected: --merge specified but no unmerged files are within file "
"limit."
msgstr ""
-"Nincsen fájl kiválasztva: --merge megadva, de nincsenek unmerged fájlok a fájlon
-belül "
+"Nincsen fájl kiválasztva: --merge megadva, de nincsenek unmerged fájlok a fájlon belül "
"limit."
#: gitk:361 gitk:508
@@ -662,8 +661,7 @@ msgstr "Nem előd"
#: gitk:4842
msgid "Local changes checked in to index but not committed"
-msgstr "Lokális változtatások, melyek be vannak téve az indexbe, de még
-nincsenek commitolva"
+msgstr "Lokális változtatások, melyek be vannak téve az indexbe, de még nincsenek commitolva"
#: gitk:4878
msgid "Local uncommitted changes, not checked in to index"
^ permalink raw reply related
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Paul Mackerras @ 2009-12-14 3:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Laszlo Papp, Laszlo Papp, git
In-Reply-To: <7vskbejmrw.fsf@alter.siamese.dyndns.org>
On Sun, Dec 13, 2009 at 06:46:11PM -0800, Junio C Hamano wrote:
> Paul Mackerras <paulus@samba.org> writes:
>
> > In any case, your patch has problems: I applied it and then ran
> > make to update the message catalogs, and I got these errors:
> >
> > Generating catalog po/hu.msg
> > msgfmt --statistics --tcl po/hu.po -l hu -d po/
> > po/hu.po:41: end-of-line within string
> > po/hu.po:41:4: syntax error
> > po/hu.po:42: end-of-line within string
> > po/hu.po:666: end-of-line within string
> > po/hu.po:666:10: syntax error
> > po/hu.po:667: end-of-line within string
> > msgfmt: found 6 fatal errors
> > make: *** [po/hu.msg] Error 1
> >
> > so I reverted it.
>
> Syntactically there seem to be only two line-wrapping caused by MUA on the
> originating side that caused this. Munging the problematic lines seems to
> fix the above.
It didn't look to me as though it was just MUA line-wrapping, since
there was a '+' at the start of the line following the one that didn't
have a closing quote. Also, git am didn't complain about it, which it
would have done if it had been MUA line-wrapping.
> Now, I don't read _any_ Hungarian, so it could very well be that my fix-up
> is wrong and there shouldn't be any SP between two words in 'fájlon belül'
> and 'még nincsenek'; if we hear from some Hungarian capable readers that the
> fix-up below makes sense, perhaps squashing it in would be the easiest way
> to move forward?
I also don't read any Hungarian, which is why I didn't want to try to
fix up problems that were more than just MUA line-wrapping. As you
say, if a Hungarian speaker can verify that your fix is correct, we
could fix up the original patch. A clean re-post with a suitable
subject would be nicer, though.
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Junio C Hamano @ 2009-12-14 4:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Laszlo Papp, Laszlo Papp, git
In-Reply-To: <20091214032816.GB24152@drongo>
Paul Mackerras <paulus@samba.org> writes:
> I also don't read any Hungarian, which is why I didn't want to try to
> fix up problems that were more than just MUA line-wrapping. As you
> say, if a Hungarian speaker can verify that your fix is correct, we
> could fix up the original patch. A clean re-post with a suitable
> subject would be nicer, though.
You are right on all counts (the breakage was inside the editor of the
author before the commit was made, the "fix-up" is more than just a MUA
breakage, and a clean re-post with a proper title would be nicer).
Thanks.
^ permalink raw reply
* Re: git --version wrong
From: B Smith-Mannschott @ 2009-12-14 6:17 UTC (permalink / raw)
To: oshybrid; +Cc: git
In-Reply-To: <26770625.post@talk.nabble.com>
On Sun, Dec 13, 2009 at 23:51, oshybrid <oshybrid@gmail.com> wrote:
>
> After i Instal 1.6.5.5 my "git --version" still shows 1.6.0.5
>
How, exactly, did you install it?
What's the output when you type "which git" at the command line?
// Ben
^ permalink raw reply
* How can I get full filenames from Git difftool (for Microsoft Word “Compare Documents” feature)?
From: Doug Ireton @ 2009-12-14 6:25 UTC (permalink / raw)
To: git
In-Reply-To: <b507cb050912132222x7e1daa9cw73b13f3db0ee22c6@mail.gmail.com>
I am using the latest version of Git (1.6.6) on a Mac. My wife wants
to use Git to manage her fiction writing as long as she can still use
Microsoft Word 2008 (Mac). Instead of pushing her into saving
everything as plain text, I would like to use Git Difftool to pass the
files to Word and use Word's Compare Documents feature. She wouldn't
be able to use Git Diff since Word docs are binary files but she could
still use Git Difftool.
I have written an Applescript which takes two filenames in this
format: /Users/foo/Documents/my_novel.docx and opens Word to do the
file comparison. However, Git Difftool seems to only pass the bare
filenames (e.g. my_novel.docx) as parameters.
Is there anyway to get the full filenames from Git Difftool?
Thanks,
Doug Ireton
^ permalink raw reply
* Re: How can I get full filenames from Git difftool (for Microsoft Word “Compare Documents” feature)?
From: Matthieu Moy @ 2009-12-14 7:55 UTC (permalink / raw)
To: Doug Ireton; +Cc: git
In-Reply-To: <b507cb050912132225j1bdc39c2v42a3bf6bddf1cb1a@mail.gmail.com>
Doug Ireton <dougireton@gmail.com> writes:
> I am using the latest version of Git (1.6.6) on a Mac. My wife wants
> to use Git to manage her fiction writing as long as she can still use
> Microsoft Word 2008 (Mac). Instead of pushing her into saving
> everything as plain text, I would like to use Git Difftool to pass the
> files to Word and use Word's Compare Documents feature. She wouldn't
> be able to use Git Diff since Word docs are binary files but she could
> still use Git Difftool.
If you're interested in diff-ing the _text_ itself, you can use the
textconv filter of Git, together with antiword (or catdoc, which does
the same thing, but I think antiword works better).
See this:
http://git.or.cz/gitwiki/GitTips#HowtousegittotrackOpenDocument.28OpenOffice.2CKoffice.29files.3F
and adapt by replacing "OpenOffice" with MS Word, and odt2txt with
antiword.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Yann Dirson @ 2009-12-10 8:35 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: kusmabite, Ferry Huberts, GIT ml
In-Reply-To: <4B200EF5.2060606@gmail.com>
On Wed, Dec 09, 2009 at 09:56:21PM +0100, Marius Storm-Olsen wrote:
> Yann Dirson said the following on 08.12.2009 15:37:
> >On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote:
> >>You can follow the discussion here:
> >>http://code.google.com/p/msysgit/issues/detail?id=288
> >>
> >>I believe the reason is something like "because someone suggested
> >>it, and no one disagreed". Do you have a good argument why it
> >>shouldn't be the default (other than "it's a change", because
> >>changing it back now would also be a change)?
> >
> >Depending on the opinion of the Eclipse guys on this issue about
> >"writing to hidden files only says 'could not write'", which
> >arguably could be seen as a bug on their side, we can see changing
> >this behaviour back to the default on the msysgit side as either a
> >(possibly temporary) workaround for a known eclipse bug, or as
> >getting again interoperable with egit.
>
> Dot-files on unix are considered hidden. It's the only way files are
> hidden there. Not so on Windows. Dot-files are just like any normal
> file, and you need to mark a file hidden.
>
> So, the logic of egit, that *actually* hidden files should not be
> written to, but dot-files should, seems to me to be a bug in egit.
> There should be no reason why egit shouldn't be able to write to any
> file, pending permissions. I'd say file a bug report with egit.
Actually it is not egit who is unable to write to the file, but
eclipse itself, and I do tend to think it is a bug in eclipse. But
now, even if we can convince the eclipse guys that it is a bug, it
will be some time before a new release with this bug fixed gets
published.
So IMHO it would makes sense, for the sake of usability, to not
activate the "hide dotfiles" feature by default. It is easier for
someone seeing unwanted dotfiles to find the switch to hide them, than
for someone getting a "could not write" message from eclipse to
understand that there is a seemingly-unrelate switch for msysgit to
avoid this situation.
But maybe the situation is not so clear. That "hide dotfiles" was
implemented so that ".git" at first, and then ".git*" files do not
clutter the view of the project. But then, if a git repo has other
dotfiles, those are really *part of* the versionned stuff, so I do not
see why those should be hidden at all. After all, the .project,
.classpath, and other eclipse project files have that name on windows
too, and it will indeed *confuse* people to get them hidden.
So should we have 2 classes of dotfiles, those "private to git", and
the others, one class being hidden while the others are not ? I am
not sure at all this would be a good idea either. Or maybe we should
only get .git hidden - after all, that one is the only real metadata
not part of the versionned stuff itself ?
Maybe we should add some sort of "core.hidedotfiles = dotgitonly"
setting, and make that the default ? That one does not appear to
cause any problems to jgit, and eclipse itself has not business with
it, so it would IMHO make sense.
Opinions ?
^ permalink raw reply
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Erik Faye-Lund @ 2009-12-14 9:13 UTC (permalink / raw)
To: Yann Dirson; +Cc: Marius Storm-Olsen, Ferry Huberts, GIT ml
In-Reply-To: <20091210083514.GA5971@linagora.com>
On Thu, Dec 10, 2009 at 9:35 AM, Yann Dirson <ydirson@linagora.com> wrote:
> On Wed, Dec 09, 2009 at 09:56:21PM +0100, Marius Storm-Olsen wrote:
>> Yann Dirson said the following on 08.12.2009 15:37:
>> >On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote:
>> >>You can follow the discussion here:
>> >>http://code.google.com/p/msysgit/issues/detail?id=288
>> >>
>> >>I believe the reason is something like "because someone suggested
>> >>it, and no one disagreed". Do you have a good argument why it
>> >>shouldn't be the default (other than "it's a change", because
>> >>changing it back now would also be a change)?
>> >
>> >Depending on the opinion of the Eclipse guys on this issue about
>> >"writing to hidden files only says 'could not write'", which
>> >arguably could be seen as a bug on their side, we can see changing
>> >this behaviour back to the default on the msysgit side as either a
>> >(possibly temporary) workaround for a known eclipse bug, or as
>> >getting again interoperable with egit.
>>
>> Dot-files on unix are considered hidden. It's the only way files are
>> hidden there. Not so on Windows. Dot-files are just like any normal
>> file, and you need to mark a file hidden.
>>
>> So, the logic of egit, that *actually* hidden files should not be
>> written to, but dot-files should, seems to me to be a bug in egit.
>> There should be no reason why egit shouldn't be able to write to any
>> file, pending permissions. I'd say file a bug report with egit.
>
> Actually it is not egit who is unable to write to the file, but
> eclipse itself, and I do tend to think it is a bug in eclipse. But
> now, even if we can convince the eclipse guys that it is a bug, it
> will be some time before a new release with this bug fixed gets
> published.
>
> So IMHO it would makes sense, for the sake of usability, to not
> activate the "hide dotfiles" feature by default. It is easier for
> someone seeing unwanted dotfiles to find the switch to hide them, than
> for someone getting a "could not write" message from eclipse to
> understand that there is a seemingly-unrelate switch for msysgit to
> avoid this situation.
>
Actually, I think it makes much more sense to put a note of the issue
in the release-notes. I don't want people to lose features because
Eclipse, an IDE I don't even use, is broken. Since Eclipse is the
culprit here, I think it's the Eclipse that should "take the hit", not
the rest of us.
This of course assumes that hidden dotfiles is a feature that people
want, which is what I assumed was the reason why it was added in the
first place. Personally I don't care about this feature, since I have
the "show hidden files"-feature turned on.
> But maybe the situation is not so clear. That "hide dotfiles" was
> implemented so that ".git" at first, and then ".git*" files do not
> clutter the view of the project. But then, if a git repo has other
> dotfiles, those are really *part of* the versionned stuff, so I do not
> see why those should be hidden at all. After all, the .project,
> .classpath, and other eclipse project files have that name on windows
> too, and it will indeed *confuse* people to get them hidden.
>
> So should we have 2 classes of dotfiles, those "private to git", and
> the others, one class being hidden while the others are not ? I am
> not sure at all this would be a good idea either. Or maybe we should
> only get .git hidden - after all, that one is the only real metadata
> not part of the versionned stuff itself ?
>
> Maybe we should add some sort of "core.hidedotfiles = dotgitonly"
> setting, and make that the default ? That one does not appear to
> cause any problems to jgit, and eclipse itself has not business with
> it, so it would IMHO make sense.
>
> Opinions ?
>
IF we were to go down this path, perhaps it would be even better to
use some sort of file-pattern or even squeeze this into gitattributes?
I guess something like ".* +hidden" should emulate the unix behaviour
(given that we add a hidden attribute). I don't think we have a global
gitattributes file though, so it'd have to be added to each repo where
the effect is desired, I guess.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH 00/23] nd/sparse reroll
From: Nguyễn Thái Ngọc Duy @ 2009-12-14 10:30 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
Compared to the current series in pu, patch "Teach Git to respect
skip-worktree (reading part)" has been broken up into smaller patches.
builtin-commit.c is also fixed to make the two failed test cases in
t7011 now pass. Skip-worktree bit no longer relies on
CE_MATCH_IGNORE_VALID flag, which means
"git update-index --really-refresh" respects skip-worktree bit too.
The rest is unchanged.
Nguyễn Thái Ngọc Duy (23):
update-index: refactor mark_valid() in preparation for new options
Add test-index-version
Introduce "skip-worktree" bit in index, teach Git to get/set this bit
update-index: ignore update request if it's skip-worktree
Teach ls-files and update-index to respect skip-worktree bit
Teach diff machinery to respect skip-worktree bit
Teach grep to respect skip-worktree bit
Teach commit to respect skip-worktree bit
Teach Git to respect skip-worktree bit (writing part)
Avoid writing to buffer in add_excludes_from_file_1()
Read .gitignore from index if it is skip-worktree
unpack-trees(): carry skip-worktree bit over in merged_entry()
excluded_1(): support exclude files in index
dir.c: export excluded_1() and add_excludes_from_file_1()
Introduce "sparse checkout"
unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
unpack-trees.c: generalize verify_* functions
unpack-trees(): "enable" sparse checkout and load
$GIT_DIR/info/sparse-checkout
unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final
index
unpack-trees(): ignore worktree check outside checkout area
read-tree: add --no-sparse-checkout to disable sparse checkout
support
Add tests for sparse checkout
sparse checkout: inhibit empty worktree
.gitignore | 1 +
Documentation/config.txt | 4 +
Documentation/git-ls-files.txt | 1 +
Documentation/git-read-tree.txt | 52 ++++++-
Documentation/git-update-index.txt | 29 ++++
Documentation/technical/api-directory-listing.txt | 3 +
Makefile | 1 +
builtin-apply.c | 2 +-
builtin-clean.c | 4 +-
builtin-commit.c | 11 +-
builtin-grep.c | 2 +-
builtin-ls-files.c | 11 +-
builtin-read-tree.c | 4 +-
builtin-update-index.c | 78 ++++++----
cache.h | 10 +-
config.c | 5 +
diff-lib.c | 5 +-
diff.c | 2 +-
dir.c | 100 ++++++++----
dir.h | 4 +
entry.c | 2 +-
environment.c | 1 +
read-cache.c | 17 ++-
t/t1011-read-tree-sparse-checkout.sh | 150 +++++++++++++++++
t/t2104-update-index-skip-worktree.sh | 57 +++++++
t/t3001-ls-files-others-exclude.sh | 22 +++
t/t7011-skip-worktree-reading.sh | 158 ++++++++++++++++++
t/t7012-skip-worktree-writing.sh | 139 ++++++++++++++++
t/t7300-clean.sh | 19 +++
test-index-version.c | 14 ++
unpack-trees.c | 181 +++++++++++++++++++--
unpack-trees.h | 6 +
32 files changed, 994 insertions(+), 101 deletions(-)
create mode 100755 t/t1011-read-tree-sparse-checkout.sh
create mode 100755 t/t2104-update-index-skip-worktree.sh
create mode 100755 t/t7011-skip-worktree-reading.sh
create mode 100755 t/t7012-skip-worktree-writing.sh
create mode 100644 test-index-version.c
^ permalink raw reply
* [PATCH 05/23] Teach ls-files and update-index to respect skip-worktree bit
From: Nguyễn Thái Ngọc Duy @ 2009-12-14 10:30 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1260786666-8405-1-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-ls-files.c | 2 +
builtin-update-index.c | 38 +++++++-----
t/t7011-skip-worktree-reading.sh | 114 ++++++++++++++++++++++++++++++++++++++
3 files changed, 138 insertions(+), 16 deletions(-)
create mode 100755 t/t7011-skip-worktree-reading.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index c1afbad..ad7e447 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -194,6 +194,8 @@ static void show_files(struct dir_struct *dir, const char *prefix)
continue;
if (ce->ce_flags & CE_UPDATE)
continue;
+ if (ce_skip_worktree(ce))
+ continue;
err = lstat(ce->name, &st);
if (show_deleted && err)
show_ce_entry(tag_removed, ce);
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 5e97d09..97b9ea6 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -172,29 +172,29 @@ static int process_directory(const char *path, int len, struct stat *st)
return error("%s: is a directory - add files inside instead", path);
}
-/*
- * Process a regular file
- */
-static int process_file(const char *path, int len, struct stat *st)
-{
- int pos = cache_name_pos(path, len);
- struct cache_entry *ce = pos < 0 ? NULL : active_cache[pos];
-
- if (ce && S_ISGITLINK(ce->ce_mode))
- return error("%s is already a gitlink, not replacing", path);
-
- return add_one_path(ce, path, len, st);
-}
-
static int process_path(const char *path)
{
- int len;
+ int pos, len;
struct stat st;
+ struct cache_entry *ce;
len = strlen(path);
if (has_symlink_leading_path(path, len))
return error("'%s' is beyond a symbolic link", path);
+ pos = cache_name_pos(path, len);
+ ce = pos < 0 ? NULL : active_cache[pos];
+ if (ce && ce_skip_worktree(ce)) {
+ /*
+ * working directory version is assumed "good"
+ * so updating it does not make sense.
+ * On the other hand, removing it from index should work
+ */
+ if (allow_remove && remove_file_from_cache(path))
+ return error("%s: cannot remove from the index", path);
+ return 0;
+ }
+
/*
* First things first: get the stat information, to decide
* what to do about the pathname!
@@ -205,7 +205,13 @@ static int process_path(const char *path)
if (S_ISDIR(st.st_mode))
return process_directory(path, len, &st);
- return process_file(path, len, &st);
+ /*
+ * Process a regular file
+ */
+ if (ce && S_ISGITLINK(ce->ce_mode))
+ return error("%s is already a gitlink, not replacing", path);
+
+ return add_one_path(ce, path, len, &st);
}
static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
diff --git a/t/t7011-skip-worktree-reading.sh b/t/t7011-skip-worktree-reading.sh
new file mode 100755
index 0000000..ede3ee1
--- /dev/null
+++ b/t/t7011-skip-worktree-reading.sh
@@ -0,0 +1,114 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Nguyễn Thái Ngọc Duy
+#
+
+test_description='skip-worktree bit test'
+
+. ./test-lib.sh
+
+cat >expect.full <<EOF
+H 1
+H 2
+H init.t
+H sub/1
+H sub/2
+EOF
+
+cat >expect.skip <<EOF
+S 1
+H 2
+H init.t
+S sub/1
+H sub/2
+EOF
+
+NULL_SHA1=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
+ZERO_SHA1=0000000000000000000000000000000000000000
+setup_absent() {
+ test -f 1 && rm 1
+ git update-index --remove 1 &&
+ git update-index --add --cacheinfo 100644 $NULL_SHA1 1 &&
+ git update-index --skip-worktree 1
+}
+
+test_absent() {
+ echo "100644 $NULL_SHA1 0 1" > expected &&
+ git ls-files --stage 1 > result &&
+ test_cmp expected result &&
+ test ! -f 1
+}
+
+setup_dirty() {
+ git update-index --force-remove 1 &&
+ echo dirty > 1 &&
+ git update-index --add --cacheinfo 100644 $NULL_SHA1 1 &&
+ git update-index --skip-worktree 1
+}
+
+test_dirty() {
+ echo "100644 $NULL_SHA1 0 1" > expected &&
+ git ls-files --stage 1 > result &&
+ test_cmp expected result &&
+ echo dirty > expected
+ test_cmp expected 1
+}
+
+test_expect_success 'setup' '
+ test_commit init &&
+ mkdir sub &&
+ touch ./1 ./2 sub/1 sub/2 &&
+ git add 1 2 sub/1 sub/2 &&
+ git update-index --skip-worktree 1 sub/1 &&
+ git ls-files -t > result &&
+ test_cmp expect.skip result
+'
+
+test_expect_success 'update-index' '
+ setup_absent &&
+ git update-index 1 &&
+ test_absent
+'
+
+test_expect_success 'update-index' '
+ setup_dirty &&
+ git update-index 1 &&
+ test_dirty
+'
+
+test_expect_success 'update-index --remove' '
+ setup_absent &&
+ git update-index --remove 1 &&
+ test -z "$(git ls-files 1)" &&
+ test ! -f 1
+'
+
+test_expect_success 'update-index --remove' '
+ setup_dirty &&
+ git update-index --remove 1 &&
+ test -z "$(git ls-files 1)" &&
+ echo dirty > expected &&
+ test_cmp expected 1
+'
+
+test_expect_success 'ls-files --delete' '
+ setup_absent &&
+ test -z "$(git ls-files -d)"
+'
+
+test_expect_success 'ls-files --delete' '
+ setup_dirty &&
+ test -z "$(git ls-files -d)"
+'
+
+test_expect_success 'ls-files --modified' '
+ setup_absent &&
+ test -z "$(git ls-files -m)"
+'
+
+test_expect_success 'ls-files --modified' '
+ setup_dirty &&
+ test -z "$(git ls-files -m)"
+'
+
+test_done
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* [PATCH 09/23] Teach Git to respect skip-worktree bit (writing part)
From: Nguyễn Thái Ngọc Duy @ 2009-12-14 10:30 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy, Junio C Hamano
In-Reply-To: <1260786666-8405-1-git-send-email-pclouds@gmail.com>
This part is mainly to remove CE_VALID shortcuts (and as a
consequence, ce_uptodate() shortcuts as it may be turned on by
CE_VALID) in writing code path if skip-worktree is used. Various tests
are added to avoid future breakages.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7012-skip-worktree-writing.sh | 139 ++++++++++++++++++++++++++++++++++++++
unpack-trees.c | 4 +-
2 files changed, 141 insertions(+), 2 deletions(-)
create mode 100755 t/t7012-skip-worktree-writing.sh
diff --git a/t/t7012-skip-worktree-writing.sh b/t/t7012-skip-worktree-writing.sh
new file mode 100755
index 0000000..c75efe4
--- /dev/null
+++ b/t/t7012-skip-worktree-writing.sh
@@ -0,0 +1,139 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Nguyễn Thái Ngọc Duy
+#
+
+test_description='test worktree writing operations when skip-worktree is used'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ test_commit init &&
+ echo modified >> init.t &&
+ touch added &&
+ git add init.t added &&
+ git commit -m "modified and added" &&
+ git tag top
+'
+
+test_expect_success 'read-tree updates worktree, absent case' '
+ git checkout -f top &&
+ git update-index --skip-worktree init.t &&
+ rm init.t &&
+ git read-tree -m -u HEAD^ &&
+ echo init > expected &&
+ test_cmp expected init.t
+'
+
+test_expect_success 'read-tree updates worktree, dirty case' '
+ git checkout -f top &&
+ git update-index --skip-worktree init.t &&
+ echo dirty >> init.t &&
+ test_must_fail git read-tree -m -u HEAD^ &&
+ grep -q dirty init.t &&
+ test "$(git ls-files -t init.t)" = "S init.t" &&
+ git update-index --no-skip-worktree init.t
+'
+
+test_expect_success 'read-tree removes worktree, absent case' '
+ git checkout -f top &&
+ git update-index --skip-worktree added &&
+ rm added &&
+ git read-tree -m -u HEAD^ &&
+ test ! -f added
+'
+
+test_expect_success 'read-tree removes worktree, dirty case' '
+ git checkout -f top &&
+ git update-index --skip-worktree added &&
+ echo dirty >> added &&
+ test_must_fail git read-tree -m -u HEAD^ &&
+ grep -q dirty added &&
+ test "$(git ls-files -t added)" = "S added" &&
+ git update-index --no-skip-worktree added
+'
+
+NULL_SHA1=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
+ZERO_SHA0=0000000000000000000000000000000000000000
+setup_absent() {
+ test -f 1 && rm 1
+ git update-index --remove 1 &&
+ git update-index --add --cacheinfo 100644 $NULL_SHA1 1 &&
+ git update-index --skip-worktree 1
+}
+
+test_absent() {
+ echo "100644 $NULL_SHA1 0 1" > expected &&
+ git ls-files --stage 1 > result &&
+ test_cmp expected result &&
+ test ! -f 1
+}
+
+setup_dirty() {
+ git update-index --force-remove 1 &&
+ echo dirty > 1 &&
+ git update-index --add --cacheinfo 100644 $NULL_SHA1 1 &&
+ git update-index --skip-worktree 1
+}
+
+test_dirty() {
+ echo "100644 $NULL_SHA1 0 1" > expected &&
+ git ls-files --stage 1 > result &&
+ test_cmp expected result &&
+ echo dirty > expected
+ test_cmp expected 1
+}
+
+cat >expected <<EOF
+S 1
+H 2
+H init.t
+S sub/1
+H sub/2
+EOF
+
+test_expect_success 'index setup' '
+ git checkout -f init &&
+ mkdir sub &&
+ touch ./1 ./2 sub/1 sub/2 &&
+ git add 1 2 sub/1 sub/2 &&
+ git update-index --skip-worktree 1 sub/1 &&
+ git ls-files -t > result &&
+ test_cmp expected result
+'
+
+test_expect_success 'git-add ignores worktree content' '
+ setup_absent &&
+ git add 1 &&
+ test_absent
+'
+
+test_expect_success 'git-add ignores worktree content' '
+ setup_dirty &&
+ git add 1 &&
+ test_dirty
+'
+
+test_expect_success 'git-rm fails if worktree is dirty' '
+ setup_dirty &&
+ test_must_fail git rm 1 &&
+ test_dirty
+'
+
+cat >expected <<EOF
+Would remove expected
+Would remove result
+EOF
+test_expect_success 'git-clean, absent case' '
+ setup_absent &&
+ git clean -n > result &&
+ test_cmp expected result
+'
+
+test_expect_success 'git-clean, dirty case' '
+ setup_dirty &&
+ git clean -n > result &&
+ test_cmp expected result
+'
+
+test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index 4870da9..1ab3c89 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -450,7 +450,7 @@ static int verify_uptodate(struct cache_entry *ce,
{
struct stat st;
- if (o->index_only || o->reset || ce_uptodate(ce))
+ if (o->index_only || (!ce_skip_worktree(ce) && (o->reset || ce_uptodate(ce))))
return 0;
if (!lstat(ce->name, &st)) {
@@ -1004,7 +1004,7 @@ int oneway_merge(struct cache_entry **src, struct unpack_trees_options *o)
if (old && same(old, a)) {
int update = 0;
- if (o->reset && !ce_uptodate(old)) {
+ if (o->reset && !ce_uptodate(old) && !ce_skip_worktree(old)) {
struct stat st;
if (lstat(old->name, &st) ||
ie_match_stat(o->src_index, old, &st, CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE))
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* [PATCH 10/23] Avoid writing to buffer in add_excludes_from_file_1()
From: Nguyễn Thái Ngọc Duy @ 2009-12-14 10:30 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy, Junio C Hamano
In-Reply-To: <1260786666-8405-1-git-send-email-pclouds@gmail.com>
In the next patch, the buffer that is being used within
add_excludes_from_file_1() comes from another function and does not
have extra space to put \n at the end.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
dir.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/dir.c b/dir.c
index e05b850..1170d64 100644
--- a/dir.c
+++ b/dir.c
@@ -229,10 +229,9 @@ static int add_excludes_from_file_1(const char *fname,
if (buf_p)
*buf_p = buf;
- buf[size++] = '\n';
entry = buf;
- for (i = 0; i < size; i++) {
- if (buf[i] == '\n') {
+ for (i = 0; i <= size; i++) {
+ if (i == size || buf[i] == '\n') {
if (entry != buf + i && entry[0] != '#') {
buf[i - (i && buf[i-1] == '\r')] = 0;
add_exclude(entry, base, baselen, which);
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
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