* 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/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: 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: 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: 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: [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: 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 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: 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: 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
* 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: [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
* 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 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
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Štěpán Němec @ 2009-12-13 19:03 UTC (permalink / raw)
To: Laszlo Papp; +Cc: Paul Mackerras, Laszlo Papp, git
In-Reply-To: <a362e8010912131030v4c1ef231r7246d7291f6a5677@mail.gmail.com>
On Sun, Dec 13, 2009 at 07:30:21PM +0100, Laszlo Papp wrote:
> On Sun, Nov 29, 2009 at 3:33 AM, Laszlo Papp <djszapi@archlinux.us> wrote:
> > On Sun, Nov 22, 2009 at 9:05 AM, Laszlo Papp <djszapi@archlinux.us> wrote:
> >> On Thu, Nov 19, 2009 at 10:07 AM, Paul Mackerras <paulus@samba.org> wrote:
> >>> Laszlo Papp writes:
> >>>
> >>>> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
> >>>> ---
> >>>> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>
> >>> Is there a patch 1/2 that needs to be applied first, as the subject
> >>> line might imply?
> >>>
> >>> Paul.
> >>>
> >>
> >> It's the file of the new hungarian translation, it can be applied
> >> alone without any plus file/patch.
> >>
> >> Best Regards,
> >> Laszlo Papp
> >>
> >
> > Up!
> >
>
> 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... :(
Please don't ignore your dream.
It's just that this is a relatively high-traffic list most of the time
(in my limited experience), so it does occasionally happen that your
patch gets "stuck" somehow; it's probably only more likely to happen if
you're trying to contribute to something non-core, like gitk in this
case (simply because there are less developers "available").
The only thing you should do is try to get attention -- usually just
sending an e-mail suffices, maybe preferably with some more useful
content than "Up!". If it doesn't, well, try again (according to my
accounting, you did it actually only once so far, definitely not six
times).
I'm sure your patch will get the attention and handling it deserves (I
experienced similar problem not too long ago), so -- please don't give
up!
Thank you!
Štěpán
[who is just a reader of the list most of the time, so can't really
help you more with this]
^ permalink raw reply
* Re: [PATCH 2/2] Add gitk-git Hungarian translation
From: Laszlo Papp @ 2009-12-13 18:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Laszlo Papp, git
In-Reply-To: <a362e8010911281833p58058a06sbe305d61709ac051@mail.gmail.com>
On Sun, Nov 29, 2009 at 3:33 AM, Laszlo Papp <djszapi@archlinux.us> wrote:
> On Sun, Nov 22, 2009 at 9:05 AM, Laszlo Papp <djszapi@archlinux.us> wrote:
>> On Thu, Nov 19, 2009 at 10:07 AM, Paul Mackerras <paulus@samba.org> wrote:
>>> Laszlo Papp writes:
>>>
>>>> Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
>>>> ---
>>>> gitk-git/po/hu.po | 1151 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> Is there a patch 1/2 that needs to be applied first, as the subject
>>> line might imply?
>>>
>>> Paul.
>>>
>>
>> It's the file of the new hungarian translation, it can be applied
>> alone without any plus file/patch.
>>
>> Best Regards,
>> Laszlo Papp
>>
>
> Up!
>
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... :(
Best Regards,
Laszlo Papp
^ permalink raw reply
* on-any-overwrite hook, filename for smudge filter?
From: Moe @ 2009-12-13 17:55 UTC (permalink / raw)
To: git
Hello git family.
I'm looking for a way to reliably preserve permissions in a repository.
I found the excellent metastore-utility[1] (which also backs etckeeper),
but it hooks into git-pull and can miss file overwrites caused by other
operations.
The closest I found to a global "on-any-file-overwrite" hook would be
the "smudge" filter-command as described in gitattributes(5).
Unfortunately the smudge-command seems to never learn
about a filename but merely filters stdin -> stdout.
The regular hooks don't cut it either, as for example the git-merge
hook doesn't run on partial merges ("XXX needs update").
So, is there a way to run a script after git has
overwritten any local file for any reason?
Best, Moe
[1] http://git.hardeman.nu/?p=metastore.git
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Jeff King @ 2009-12-12 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl5nn9x2.fsf@alter.siamese.dyndns.org>
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.
If we are going to declare subsets of the namespace as "complete" (and
warn about unknown keys in them), then we should probably be more
thorough about it (but I don't personally think that is a good idea, as
version portability is IMHO more useful).
-Peff
^ permalink raw reply
* Re: [PATCH] Fix archive format with -- on the command line
From: René Scharfe @ 2009-12-12 15:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Ilari Liusvaara, git
In-Reply-To: <7vd42m8kyr.fsf@alter.siamese.dyndns.org>
Am 11.12.2009 00:31, schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Giving --format from the command line, or using output file extention to
>> DWIM the output format, with a pathspec that is disambiguated with an
>> explicit double-dash on the command line, e.g.
>>
>> git archive -o file --format=zip HEAD -- path
>> git archive -o file.zip HEAD -- path
>>
>> didn't work correctly.
>>
>> This was because the code reordered (when one was given) or added (when
>> the former was inferred) a --format argument at the end, effectively
>> making it to "archive HEAD -- path --format=zip", i.e. an extra pathspec
>> that is unlikely to match anything.
>
> A side note to this issue is that
>
> $ git add non-existing-path
>
> complains but
>
> $ git archive HEAD non-existing-path
>
> doesn't. Is this something we should consider a bug, or a feature?
I wouldn't go so far as to call it a bug, but it's certainly a missing
feature. If the user asks for something we can't give him or her, it's
better to report that fact. We didn't do that because it doesn't fall
out naturally from the archive streaming loop. ls-tree doesn't do it,
either, by the way.
Something like this?
-- >8 --
Subject: archive: complain about path specs that don't match anything
Verify that all path specs match at least one path in the specified
tree and reject those that don't.
This would have made the bug fixed by 782a0005 easier to find.
This implementation is simple to the point of being stupid. It walks
the full tree for each path spec until it matches something. It's short
and seems to be fast enough, though.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/archive.c b/archive.c
index 55b2732..5b88507 100644
--- a/archive.c
+++ b/archive.c
@@ -211,10 +211,33 @@ static const struct archiver *lookup_archiver(const char *name)
return NULL;
}
+static int reject_entry(const unsigned char *sha1, const char *base,
+ int baselen, const char *filename, unsigned mode,
+ int stage, void *context)
+{
+ return -1;
+}
+
+static int path_exists(struct tree *tree, const char *path)
+{
+ const char *pathspec[] = { path, NULL };
+
+ if (read_tree_recursive(tree, "", 0, 0, pathspec, reject_entry, NULL))
+ return 1;
+ return 0;
+}
+
static void parse_pathspec_arg(const char **pathspec,
struct archiver_args *ar_args)
{
- ar_args->pathspec = get_pathspec("", pathspec);
+ ar_args->pathspec = pathspec = get_pathspec("", pathspec);
+ if (pathspec) {
+ while (*pathspec) {
+ if (!path_exists(ar_args->tree, *pathspec))
+ die("path not found: %s", *pathspec);
+ pathspec++;
+ }
+ }
}
static void parse_treeish_arg(const char **argv,
^ permalink raw reply related
* Re: [PATCH 0/3] Update advice in commit/status output
From: Jay Soffian @ 2009-12-12 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1260608523-15579-1-git-send-email-gitster@pobox.com>
On Sat, Dec 12, 2009 at 4:02 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian noticed that we give "git reset HEAD <path>" as an instruction
> to get rid of the local change that has already been added to the index
> even when <path> is unmerged, or it is merged and we are about to commit a
> merge.
>
> In neither case, "git reset HEAD <path>" is absolutely a wrong thing to do
> while merging.
>
> This miniseries updates the advices given in status/commit. It applies on
> top of the jk/1.7.0-status topic, and has trivial conflicts in wt-status.c
> with the jk/unwanted-advices topic that has already graduated to 'maint'.
Series looks good to me after the spelling correction. Thank you.
j.
^ permalink raw reply
* Re: [PATCH] bash: Support new 'git fetch' options
From: Shawn O. Pearce @ 2009-12-12 21:24 UTC (permalink / raw)
To: Bj??rn Gustavsson, Junio C Hamano; +Cc: git
In-Reply-To: <4B236EBA.6050806@gmail.com>
Bj??rn Gustavsson <bgustavsson@gmail.com> wrote:
> Support the new options --all, --prune, and --dry-run for
> 'git fetch'.
>
> As the --multiple option was primarily introduced to enable
> 'git remote update' to be re-implemented in terms of 'git fetch'
> (16679e37) and is not likely to be used much from the command
> line, it does not seems worthwhile to complicate the code
> (to support completion of multiple remotes) to handle it.
>
> Signed-off-by: Bj??rn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Junio, this belongs in 1.6.6 as its completion support for 1.6.6
features...
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] octopus: make merge process simpler to follow
From: Johannes Sixt @ 2009-12-12 19:56 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Jari Aalto
In-Reply-To: <1260578339-30750-1-git-send-email-bebarino@gmail.com>
On Samstag, 12. Dezember 2009, Stephen Boyd wrote:
> + pretty_name="$(eval echo \$GITHEAD_$SHA1)"
eval pretty_name=\$GITHEAD_$SHA1
:)
-- Hannes
^ permalink raw reply
* Re: [PATCH v5 4/7] reset: add option "--keep" to "git reset"
From: Junio C Hamano @ 2009-12-12 21:46 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Linus Torvalds, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow, Jakub Narebski, Paolo Bonzini,
Johannes Sixt, Stephen Boyd
In-Reply-To: <20091212043259.3930.21831.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> The purpose of this new option is to discard some of the last commits
> but to keep current changes in the work tree.
>
> The use case is when you work on something and commit that work. And
> then you work on something else that touches other files, but you don't
> commit it yet. Then you realize that what you commited when you worked
> on the first thing is not good or belongs to another branch.
>
> So you want to get rid of the previous commits (at least in the current
> branch) but you want to make sure that you keep the changes you have in
> the work tree. And you are pretty sure that your changes are independent
> from what you previously commited, so you don't want the reset to
> succeed if the previous commits changed a file that you also changed in
> your work tree.
>
> The "--keep" option will do what you want.
Having two paragraphs that describe the use case near the top is a big
improvement from older rounds, but this one line is more irritating than
useful, as it tries to be convincing only by being repetitive. The only
new information it adds relative to the first two lines is its name. The
true convincing argument immediately follows in the form of the table
below anyway, so I'd drop this line if I were you.
> The table below shows what happens when running "git reset --option
> target" to reset the HEAD to another commit (as a special case "target"
> could be the same as HEAD) in the cases where "--merge" and "--keep"
> behave differently.
>
> working index HEAD target working index HEAD
> ----------------------------------------------------
> A B C D --keep (disallowed)
> --merge (disallowed)
Ok. the user has partially updated the index and has further changes; we
don't want to lose either of them. During a failed merge, this cannot
happen, so it is a good safety measure on "--merge" side as well.
> A B C C --keep A C C
> --merge (disallowed)
The user started working based on C, and has partially updated the index.
This cannot have come from a failed automerge because A != B, so using
"reset --merge" is likely to be a mistake and we should disallow it as a
safety measure.
> B B C D --keep (disallowed)
> --merge C C C
For --keep this is the same as the first case (except that the "partially
updated the index" happened to be "100% pertially") and it makes sense to
disallow it.
However, I think --merge _should_ have D (target) in all of the three in
the result in this case, as I mentioned in my response to [PATCH 3/7]. Is
that "the bug" you talked about there?
> B B C C --keep B C C
> --merge C C C
A special case of the second one for --keep. For --merge, B can only have
come from the previous merge operation we are resetting away, and matching
all three result to the "C", which is the target, is the right thing to do.
> So as can be seen in the table, "--merge" can discard changes in the
> working tree, while "--keep" does not. So if one wants to avoid using
> "git stash" before and after using "git reset" to save current changes,
> it is better to use "--keep" rather than "--merge".
This is a very flawed and misleading description. These two options serve
two entirely different purposes and use cases, but your "if one wants to
avoid using ... to save current changes" is too broad and does not
distinguish between the two. "--keep" option is valid (or "better") for
only one of them, while it is absolutely the wrong option to use for the
other one. So it may be "better" only half the time and it is wrong in
the other half.
The precondition of using a --merge is the scenario Linus described in
9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01). You started some
mergy operation and ended up in a state where all the differences, either
merged or unmerged, between the HEAD and the index came from the mergy
operation. Also the paths in the work tree that correspond to the index
entries with differences from HEAD are modified by the mergy operation
(either updated with a cleanly resolved merge, or with conflict markers)
and do not match HEAD when "reset --merge" is run, but it is guaranteed
that you didn't have any local modification to them before the mergy
operation. You do want to reset these changes to the work tree away,
while keeping the changes you had before the mergy operation.
"--merge" not only _can_ (as in "has the risk to") discard changes, but in
the "failed merge" scenario, it is absolutely the right thing to do to
discard the changes in the work tree for the paths that have differences
between HEAD and index and to update them to that of the target. Not
updating like "--keep" does is not "better" but is simply _wrong_.
The use case "--keep" wants to support is very different (and you have a
good description near the beginning of the commit log message for people
to judge if the intended use case makes sense). For it, discarding the
changes to the work tree is a wrong thing to do.
> The following table shows what happens on unmerged entries:
>
> working index HEAD target working index HEAD
> ----------------------------------------------------
> X U A B --keep X B B
> --merge X B B
> X U A A --keep X A A
> --merge (disallowed)
>
> In this table X can be any state and U means an unmerged entry.
I am wondering if we should disallow "--keep" if we see unmerged entries
in the index as a minimum safety measure. Failing "reset --keep" when an
unmerged entry exists in the index will save people who are trying to
discard a failed merge (i.e. who should have used --merge) but was somehow
fooled into thinking that "--keep" is a better "--merge".
It also is tempting to say that we should forbid "reset --merge" without
an unmerged entry in the index, but that wouldn't work. A mergy operation
would have left unmerged entries in the index initially before giving the
control back to the user, but the user may have used "edit && git add" to
resolve them, and then decided that it is not worth committing. By the
time "reset --merge" is run, there may not be any unmerged path left in
the index.
I am suggesting extra safety measures primarily because I am worried that
people will get confused by these two similar looking options that are
meant for entirely different use cases. An obvious alternative solution
to avoid the confusion is not to add "--keep" in the first place. While I
think that is rather a cop-out than a solution, it might make more sense.
It is hopeless to educate users to pick the right one, if even the author
of the new option mistakenly thinks that "--keep is merely a better
version of --merge".
My preference is at this point to first have patches [1/7] to [3/7] to
update "reset --merge" (I am not sure about the "--mixed in $GIT_DIR"
change, though), with a new follow-up patch [3.5/7] to fix "reset --merge"
to reset paths that were cloberred by the merge to the target (not HEAD),
and start cooking these changes in 'pu' and then 'next'.
That will lay groundwork of using unpack_trees() in "reset" and after they
stabilize, build new modes like "--keep" on top of it.
^ permalink raw reply
* Re: [PATCH v5 3/7] reset: use "unpack_trees()" directly instead of "git read-tree"
From: Junio C Hamano @ 2009-12-12 21:46 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Linus Torvalds, Johannes Schindelin,
Stephan Beyer, Daniel Barkalow, Jakub Narebski, Paolo Bonzini,
Johannes Sixt, Stephen Boyd
In-Reply-To: <20091212043259.3930.82570.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> As Daniel Barkalow found, there is a difference between this new
> version and the old one. The old version gives an error for
> "git reset --merge" with unmerged entries and the new version does
> not. But this can be seen as a bug fix,...
I sense that there is one crucial sentence missing here for a reader to
judge the "can be seen as a bug fix" claim. Instead of giving an error
and stopping, what _does_ this version do? If it ran "rm -rf" on the
entire work tree instead of giving an error, it wouldn't be a bugfix, for
example ;-)
> In fact there is still an error with unmerge entries if we reset
> the unmerge entries to the same state as HEAD. So the bug is not
> completely fixed.
"If we reset to HEAD then it is a bug"---and what the patch actually does
is...?
I agree with the analysis in the log message of 9e8ecea (Add 'merge' mode
to 'git reset', 2008-12-01):
If the index has unmerged entries, "--merge" will currently simply
refuse to reset ("you need to resolve your current index first").
You'll need to use "--hard" or similar in this case.
This is sad, because normally a unmerged index means that the working
tree file should have matched the source tree, so the correct action
is likely to make --merge reset such a path to the target (like --hard),
regardless of dirty state in-tree or in-index.
If I have a local change that I know is unrelated to a merge I am
going to do, I can imagine I'd work like this:
$ git pull some-where
... Some paths conflict, others merge cleanly and update
... the index, but the overall change looks horrible, and
... I decide to discard the whole thing.
$ git reset --merge HEAD
In this case HEAD is the target. Similarly, if I have a local change that
I know is unrelated to a series of patches I am applying:
$ git am -3 topic.mbox
... A few patches apply cleanly, and then the series fail
... with conflict. The overall change looks horrible, and
... I decide to discard the whole thing.
$ git reset --merge @{3.minutes.ago}
In this case, the target is the commit that I was at before starting to
apply the series---i.e. different from HEAD.
In either case, because "merge" (triggered by "pull") and "am -3" honor
the promise with the user that:
(1) no mergy (aka "integration") command stuffs an unmerged entry to an
index that is dirty with respect to HEAD (this should also apply to
"cherry-pick" and "rebase -m/-i" even though the last one is often
stricter than it is absolutely necessary); and
(2) every mergy command verifies that the index entry and the path in the
work tree do not have any local change before they are updated by it;
resetting can safely overwrite both the index entry and the path in the
work tree with contents taken from the commit we are switching to.
The updated test seems to be testing that "reset --merge HEAD^" does make
the index match the target, but it only checks "is there _any_ change",
and does not even test "which path kept the change and which path got
cloberred".
Ideally it should test "Is the change what we expect to have? Did we keep
what we should have kept, instead of clobbering? Did we discard the
changes to the path that the failed merge cloberred?", all of the three.
> diff --git a/t/t7110-reset-merge.sh b/t/t7110-reset-merge.sh
> index 8190da1..6afaf73 100755
> --- a/t/t7110-reset-merge.sh
> +++ b/t/t7110-reset-merge.sh
> @@ -79,10 +79,12 @@ test_expect_success 'setup 2 different branches' '
> git commit -a -m "change in branch2"
> '
>
> -test_expect_success '"reset --merge HEAD^" fails with pending merge' '
> +test_expect_success '"reset --merge HEAD^" is ok with pending merge' '
> test_must_fail git merge branch1 &&
> - test_must_fail git reset --merge HEAD^ &&
> - git reset --hard HEAD
> + git reset --merge HEAD^ &&
> + test -z "$(git diff --cached)" &&
> + test -n "$(git diff)" &&
> + git reset --hard HEAD@{1}
> '
>
> test_expect_success '"reset --merge HEAD" fails with pending merge' '
> --
> 1.6.6.rc1.8.gd33ec
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Junio C Hamano @ 2009-12-12 21:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091212122524.GA17547@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> When parsing the config file, if there is a value that is
> syntactically correct but unused, we generally ignore it.
> This lets non-core porcelains store arbitrary information in
> the config file, and it means that configuration files can
> be shared between new and old versions of git (the old
> versions might simply ignore certain configuration).
>
> The one exception to this is color configuration; if we
> encounter a color.{diff,branch,status}.$slot variable, we
> die if it is not one of the recognized slots (presumably as
> a safety valve for user misconfiguration).
This reminds me of the issue an earlier patch with a good intention but a
horrible consequence wanted to address.
http://thread.gmane.org/gmane.comp.version-control.git/125925/focus=127629
> This patch loosens the check to match the rest of
> git-config; unknown color slots are simply ignored.
I am of two minds, even though I am slightly in favor than against the
change.
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.
^ 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