* Re: git-mv redux: there must be something else going on
From: Ron Garret @ 2010-02-03 19:23 UTC (permalink / raw)
To: git
In-Reply-To: <32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com>
In article
<32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com>,
Avery Pennarun <apenwarr@gmail.com> wrote:
> On Wed, Feb 3, 2010 at 1:25 PM, Ron Garret <ron1@flownet.com> wrote:
> > So something in my understanding of how git works must be wrong. Git
> > must be keeping a separate record of file renames somewhere. But where?
>
> It doesn't. Your experiment is wrong.
>
> > [ron@mickey:~/devel/gittest]$ cat>file2
> > 6
> > 7
> > 8
> > 9
> > 10
> > [ron@mickey:~/devel/gittest]$ git mv file2 file3
> > [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
> > [master ae3f6d4] letters->numbers
> > 1 files changed, 0 insertions(+), 0 deletions(-)
> > rename file2 => file3 (100%)
>
> Whoops. You didn't 'git add file2' (before the mv) or 'git add file3'
> (after the mv), or use commit -a, so what you've committed is the
> *old* content of file2 under the name file3. The *new* content of
> file2 is still uncommitted in your work tree under the name file3.
> This is why git can detect the move. (The 100% is a good clue: it
> means the old and new files are 100% identical.)
Ah. That explains everything. Thanks. (I thought git mv was
equivalent to git rm followed by git add. But it's not.)
> Artificial tests like this are useless anyway.
Yes, I know. This was not intended to be a real-world example. I was
just trying to understand the heuristics that git uses to track filename
changes, and in particular, how much a file could change before git
decided it was a different file. When I got to zero shared lines
between old and new it was clear that I was missing something
fundamental :-)
So... how *does* git decide when two blobs are different blobs and when
they are the same blob with mods? I asked this question before and was
pointed to the diffcore docs, but that didn't really clear things up.
That just describes all the different ways git can do diffs, not the
actual heuristics that git uses to track content.
rg
^ permalink raw reply
* Re: extra headers in commit objects
From: Shawn O. Pearce @ 2010-02-03 19:26 UTC (permalink / raw)
To: demerphq; +Cc: Nicolas Pitre, git
In-Reply-To: <9b18b3111002031101p3385ecdfo638433bc269791aa@mail.gmail.com>
demerphq <demerphq@gmail.com> wrote:
> On 3 February 2010 19:15, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Wed, 3 Feb 2010, Shawn O. Pearce wrote:
> >
> >> Am I correct that core C developers are still under the opinion
> >> that extra headers in a commit object aren't encouraged?
> >
> > I would say so.
> >
> > [...]
> >> At the end of the day, is it a bug that C git doesn't support
> >> working with extra commit headers? ?IMHO, no, because, we've
> >> rejected these in the past, and its not part of the Git standard.
> >> And other implementations shouldn't be trying to sell it that way.
> >
> > Agreed. ?And this was discussed in great length on this list on few
> > occasions already (probably more than a year back).
>
> One problem, is that if you take the approach you say then you
> basically guarantee that a new git that DOES add new headers will
> break an old git that doesnt know about the headers, and actually
> doesnt care about them either.
As I understand it, the current stance is:
1) A compliant Git implementation ignores any headers it doesn't
recognize that appear *after* the optional "encoding" header.
2) A compliant Git implementation does not produce any additional
headers in a commit object, because other implementations cannot
perform any machine based reasoning on them.
3) All implementations would (eventually) treat all headers equally,
that is they all understand what author, committer, encoding are
and process them the same way. Any new headers should equally
be fully cross-implementation.
> So it would essentially mean that if you ever have to change the
> commit format you will be in a position where new git commits will be
> incompatible by design with old git commits.
So, we can change the format by adding a new header, after the
optional "encoding" header.
But such a change needs to be something that an older Git will
safely ignore (due to rule 1), and something that a newer Git can
make really effective use of (due to rule 2 and 3). And that newer
Git must also safely deal with commits missing that new header, due
to the huge number of commits out in the wild without said header.
And don't even get me started on amending commits with new unknown
headers. Existing implementions of Git tools will drop the extra
headers during the amend, because the headers are viewed as part
of the commit object data... and during an amend you are making a
totally new object.
For example, git-gui would drop any extra headers during an amend,
because its running `git commit-tree` directly without any way to
tell commit-tree this is for an amend of an existing commit, vs. a
completely new commit... because either way its a new commit object.
> Shouldn't an old git just ignore headers from a new git?
Yes, see above.
--
Shawn.
^ permalink raw reply
* Re: extra headers in commit objects
From: Petr Baudis @ 2010-02-03 19:26 UTC (permalink / raw)
To: demerphq; +Cc: Nicolas Pitre, Shawn O. Pearce, git
In-Reply-To: <9b18b3111002031101p3385ecdfo638433bc269791aa@mail.gmail.com>
On Wed, Feb 03, 2010 at 08:01:17PM +0100, demerphq wrote:
> Shouldn't an old git just ignore headers from a new git?
>
> I mean, forget about the fact that somebody is doing something naughty
> with the git protocol, ask youself if you want this rule to basically
> prevent any backwards compatible changes with older gits.
We have done similar changes in the past and if there would be such
a change, we can phase-in it over the course of several releases.
I think the fall-out would not be that bad; we have some experience
with even making Debian-stable Git compatible with new stuff. ;-)
Also, what if any extra header would be essential and we _wanted_
non-compatible Git to break down on it?
On the other hand, allowing this preventively would apparently have
the immediate effect of alternative implementations users happily
starting to use it, and then to get to the data, people would demand
git-core support as well. _And_ so far everyone seems really really
fairly sure we don't want the headers and it's not likely to change.
P.S.: On the other hand, I think that change was probably just
misguided, not malicious. And I wouldn't be that hard on Dulwich,
it's an early-0.x software after all, it's allowed to crash and have
protocol issues. ;-)
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Eugene Sajine @ 2010-02-03 19:27 UTC (permalink / raw)
To: Avery Pennarun
Cc: Wincent Colaiuta, Matthieu Moy, kusmabite, Johannes Schindelin,
Jacob Helwig, git
In-Reply-To: <32541b131002031057q866d3q95d0e80a0adf6c52@mail.gmail.com>
> Of course, in such editors you could just hit "space; backspace" and
> then save. Sounds annoying? Well, so does deleting all the lines in
> the commit message just to make it *not* amend.
That was exactly the starting point of my thoughts.Currently it forces
user to be explicit if he wants to cancel the operation (rebase -i,
or amend), instead of forcing user to be explicit to proceed.
>
> To reiterate what I said earlier: the mtime idea isn't even
> automatically a bad one. It's about as good as what currently exists,
> and the resulting rule (file content or mtime must be modified) is
> just as consistent as the current rule (file must be nonempty). It's
> also arguably easier for new users to understand.
OK. Agree on that.
>
> But you can't just blindly change the system to always work in a
> different way. People depend on the current behaviour.
I understand that pretty well. My logic is that the most used command
which is affecting the three is "git commit", therefore this command
workflow is pretty natural for all users, but the workflow of commit
--amend and rebase -i which are also affecting the three is
inconsistent with commit. The user interaction is not the same.
> Jeff King's script is a pretty cute solution that lets you have it your way with
> no changes to git, though.
Thanks to Jeff, I'll try it.
>
> Of course, this does open up the question of how to do any global UI
> design at all if a decision made once gets locked in forever.
100% agree, there is such question.
> The reason git is hard for new users is that its UI is crazy and
> confusing, but a major reason it keeps gaining in popularity is that
> once you learn git, you stick with it, because you don't have to
> relearn it with every new version.
I just didn't realize that this can be such a drastic change for users
as well as technical difficulties related to the emacs and similar
editors.
Thanks,
Eugene
^ permalink raw reply
* Re: extra headers in commit objects
From: demerphq @ 2010-02-03 19:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <20100203192612.GD14799@spearce.org>
On 3 February 2010 20:26, Shawn O. Pearce <spearce@spearce.org> wrote:
> demerphq <demerphq@gmail.com> wrote:
>> On 3 February 2010 19:15, Nicolas Pitre <nico@fluxnic.net> wrote:
>> > On Wed, 3 Feb 2010, Shawn O. Pearce wrote:
>> >
>> >> Am I correct that core C developers are still under the opinion
>> >> that extra headers in a commit object aren't encouraged?
>> >
>> > I would say so.
>> >
>> > [...]
>> >> At the end of the day, is it a bug that C git doesn't support
>> >> working with extra commit headers? ?IMHO, no, because, we've
>> >> rejected these in the past, and its not part of the Git standard.
>> >> And other implementations shouldn't be trying to sell it that way.
>> >
>> > Agreed. ?And this was discussed in great length on this list on few
>> > occasions already (probably more than a year back).
>>
>> One problem, is that if you take the approach you say then you
>> basically guarantee that a new git that DOES add new headers will
>> break an old git that doesnt know about the headers, and actually
>> doesnt care about them either.
>
> As I understand it, the current stance is:
>
> 1) A compliant Git implementation ignores any headers it doesn't
> recognize that appear *after* the optional "encoding" header.
Ignores but passes through?
> 2) A compliant Git implementation does not produce any additional
> headers in a commit object, because other implementations cannot
> perform any machine based reasoning on them.
>
> 3) All implementations would (eventually) treat all headers equally,
> that is they all understand what author, committer, encoding are
> and process them the same way. Any new headers should equally
> be fully cross-implementation.
>
>> So it would essentially mean that if you ever have to change the
>> commit format you will be in a position where new git commits will be
>> incompatible by design with old git commits.
>
> So, we can change the format by adding a new header, after the
> optional "encoding" header.
>
> But such a change needs to be something that an older Git will
> safely ignore (due to rule 1), and something that a newer Git can
> make really effective use of (due to rule 2 and 3). And that newer
> Git must also safely deal with commits missing that new header, due
> to the huge number of commits out in the wild without said header.
>
> And don't even get me started on amending commits with new unknown
> headers. Existing implementions of Git tools will drop the extra
> headers during the amend, because the headers are viewed as part
> of the commit object data... and during an amend you are making a
> totally new object.
>
> For example, git-gui would drop any extra headers during an amend,
> because its running `git commit-tree` directly without any way to
> tell commit-tree this is for an amend of an existing commit, vs. a
> completely new commit... because either way its a new commit object.
>
>> Shouldn't an old git just ignore headers from a new git?
>
> Yes, see above.
Right, which seems to sum to up to "that boat sailed, forget about
it", which is fair enough.
Which I say from the point of view of arbitrary headers not approved
by the git dev team. You can ensure that any new *approved* headers
have the semantics that "if they arent passed through it doesnt
matter", whereas you cant know whether a header should be passed
through or not that comes from some other source.
Well unless you introduced a convention that some header prefix is to
be preserved on amend, but other prefixes shouldnt be.
I can imagine that might be a nasty place to go tho. :-)
Anyway, thanks a lot for taking the time to explain this a bit more.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: git-gui translation updates needed
From: Junio C Hamano @ 2010-02-03 19:42 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Shawn O. Pearce, git
In-Reply-To: <201002031111.29557.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> writes:
> On Wednesday 03 February 2010, Junio C Hamano wrote:
>> - It is curious that de.po is ...
> IIRC, the timetable was:
> * Christian Stimming submits a new de.po
> * Shawn Pearce updates git-gui.pot and asks for help
> * other languages are submitted
>
> So de.po has a different date, but doesn't miss anything since
> no major change has occurred in git-gui.git in the meantime.
That explains it; thanks.
>> - I am seeing "1 untranslated", even though it.po is based on the latest
>> git-gui.pot. It translates "buckets" to an empty string; somebody who
>> care about Italian may need to double check.
>
> An empty string means "there's no translation, use the default" -- in
> this case: "buckets". I left it this way because I couldn't come up
> with a decent translation, and I wanted to keep a reminder.
I understand your intention, and I think I phrased it wrongly, as if I was
saying that you were actively telling git-gui to say nothing when it wants
to say "buckets" in English. You did the right thing by leaving it
"empty", so that other people (like me) can notice the "untranslated"
warning during build. That is why I said "somebody ... may need to double
check".
> In this case, git-gui is counting objects during a clone; would it be OK
> to consider "buckets" as synonim of "objects" or "items" or something
> else? Then I would translate accordingly.
A cursory read of the codepath with that message tells me that Shawn is
calling one [0-9a-f][0-9a-f] directory under .git/objects/ a "bucket" and
counting the number of them while copying them to implement "git clone"
inside git-gui (why?---that is a separate issue).
Calling it "objects" would be technically incorrect; using a countable
noun that does not have a particular meaning (e.g. "items") would be a
good solution for this, I think.
^ permalink raw reply
* Re: extra headers in commit objects
From: demerphq @ 2010-02-03 19:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nicolas Pitre, Shawn O. Pearce, git
In-Reply-To: <20100203192658.GP9553@machine.or.cz>
On 3 February 2010 20:26, Petr Baudis <pasky@suse.cz> wrote:
> On Wed, Feb 03, 2010 at 08:01:17PM +0100, demerphq wrote:
>> Shouldn't an old git just ignore headers from a new git?
>>
>> I mean, forget about the fact that somebody is doing something naughty
>> with the git protocol, ask youself if you want this rule to basically
>> prevent any backwards compatible changes with older gits.
>
> We have done similar changes in the past and if there would be such
> a change, we can phase-in it over the course of several releases.
> I think the fall-out would not be that bad; we have some experience
> with even making Debian-stable Git compatible with new stuff. ;-)
> Also, what if any extra header would be essential and we _wanted_
> non-compatible Git to break down on it?
Right. The only solution i can see would have had to have been
implemented already. And that would involved some headers being marked
"pass through", some "marked throw away on cherry-pick" and some
"choke horribly if you find this and dont know what it is".
And even with somethng like that one wonders if notes arent really a
better alternative to user defined headers anyway?
> On the other hand, allowing this preventively would apparently have
> the immediate effect of alternative implementations users happily
> starting to use it, and then to get to the data, people would demand
> git-core support as well. _And_ so far everyone seems really really
> fairly sure we don't want the headers and it's not likely to change.
Yes, right understood.
>
> P.S.: On the other hand, I think that change was probably just
> misguided, not malicious. And I wouldn't be that hard on Dulwich,
> it's an early-0.x software after all, it's allowed to crash and have
> protocol issues. ;-)
Heh. I have no opinion on Dulwich. Didnt even know it existed until this mail.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: gitk translation updates needed?
From: Junio C Hamano @ 2010-02-03 19:46 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git
In-Reply-To: <201002031113.11212.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> writes:
> On Wednesday 03 February 2010, Junio C Hamano wrote:
>> Generating catalog po/it.msg
>> msgfmt --statistics --tcl po/it.po -l it -d po/
>> 282 translated messages, 1 fuzzy translation, 6 untranslated messages.
>
> I don't get any fuzzy translation here, but I used to, so I guess it
> regards the copyright message. If that's the case, maybe msgfmt
> mishandles the (C)opyright sign (or maybe gitk uses a weird encoding,
> I don't know).
Sorry, I omitted a step in my report:
$ make po/gitk.pot
$ msgmerge -U po/it.po po/gitk.pot ;# and for other languages...
$ make po/it.msg
Why doesn't gitk ship with pre-generated po/gitk.pot, by the way?
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Avery Pennarun @ 2010-02-03 19:47 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-5F71CB.11234903022010@news.gmane.org>
On Wed, Feb 3, 2010 at 2:23 PM, Ron Garret <ron1@flownet.com> wrote:
> In article
> Ah. That explains everything. Thanks. (I thought git mv was
> equivalent to git rm followed by git add. But it's not.)
I suppose in this case it's not. The only difference is when your
work tree differs from your index, though, and it's to be expected
that 'git rm', in removing things from the index, would lose your
ability to track those differences.
> So... how *does* git decide when two blobs are different blobs and when
> they are the same blob with mods? I asked this question before and was
> pointed to the diffcore docs, but that didn't really clear things up.
> That just describes all the different ways git can do diffs, not the
> actual heuristics that git uses to track content.
If you really want to know the details, looking at the code really is
probably the best solution; it's not even that long.
The short version is that git chooses a set of candidate blobs, then
diffs them and figures out a percentage similarity between each pair.
(A simple way to think of the similarity index is "how long is the
diff compared to the file itself?" If the diff is of length zero, the
similarity is 100%, and so on.) If the similarity is greater than a
certain threshold, then it's considered to be the same file.
Choosing the set of candidates is actually the more interesting
problem, since detecting moves using the above algorithm is O(n^2)
with the number of candidates. That's why 'git diff' and 'git log'
don't do it at all by default.
If you provide -M, the set of candidates is the set of files that were
removed/modified and the set of files that were added. (Added files
are compared against removed/modified files, iirc.) Normally that's a
very short list. With -C, you need to compare all
added/removed/modified files with all others, which is slightly more
work. With --find-copies-harder, it becomes potentially a *lot* of
work.
Have fun,
Avery
^ permalink raw reply
* Re: git-gui clone WTFery
From: Shawn O. Pearce @ 2010-02-03 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michele Ballabio, git
In-Reply-To: <7vwryuhzsn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Michele Ballabio <barra_cuda@katamail.com> writes:
> > In this case, git-gui is counting objects during a clone; would it be OK
> > to consider "buckets" as synonim of "objects" or "items" or something
> > else? Then I would translate accordingly.
>
> A cursory read of the codepath with that message tells me that Shawn is
> calling one [0-9a-f][0-9a-f] directory under .git/objects/ a "bucket" and
> counting the number of them while copying them to implement "git clone"
> inside git-gui (why?---that is a separate issue).
I just had an argument with someone in a private thread about why
commit messages should be more than 30 characters long. Lets see
if the git-gui history stands up to that and sufficiently explains
why I rewrote clone in Tcl:
$ git blame lib/choose_repository.tcl
...
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 633)
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 634) $o_cons start \
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 635) [mc "Counting objects"] \
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 636) [mc "buckets"]
...
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 673) update
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 674)
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 675) file mkdir [file join .git objects pack]
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 676) foreach i [glob -tails -nocomplain \
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 677) -directory [file join $objdir pack] *] {
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 678) lappend tolink [file join pack $i]
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 679) }
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 680) $o_cons update [incr bcur] $bcnt
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 681) update
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 682)
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 683) foreach i $buckets {
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 684) file mkdir [file join .git objects $i]
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 685) foreach j [glob -tails -nocomplain \
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 686) -directory [file join $objdir $i] *] {
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 687) lappend tolink [file join $i $j]
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 688) }
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 689) $o_cons update [incr bcur] $bcnt
81d4d3dd (Shawn O. Pearce 2007-09-24 08:40:44 -0400 690) update
ab08b363 (Shawn O. Pearce 2007-09-22 03:47:43 -0400 691) }
Hmmph. 81d4d3dd and ab08b363 are the relevant commits:
commit 81d4d3dddc5e96aea45a2623c9b1840491348b92
Author: Shawn O. Pearce <spearce@spearce.org>
Date: Mon Sep 24 08:40:44 2007 -0400
git-gui: Keep the UI responsive while counting objects in clone
If we are doing a "standard" clone by way of hardlinking the
objects (or copying them if hardlinks are not available) the
UI can freeze up for a good few seconds while Tcl scans all
of the object directories. This is espeically noticed on a
Windows system when you are working off network shares and
need to wait for both the NT overheads and the network.
We now show a progress bar as we count the objects and build
our list of things to copy. This keeps the user amused and
also makes sure we run the Tk event loop often enough that
the window can still be dragged around the desktop.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
commit ab08b3630414dfb867825c4a5828438e1c69199d
Author: Shawn O. Pearce <spearce@spearce.org>
Date: Sat Sep 22 03:47:43 2007 -0400
git-gui: Allow users to choose/create/clone a repository
...
Rather than relying on the git-clone Porcelain that ships with
git we build the new repository ourselves and then obtain content
by git-fetch. This technique simplifies the entire clone process
to roughly: `git init && git fetch && git pull`. Today we use
three passes with git-fetch; the first pass gets us the bulk of
the objects and the branches, the second pass gets us the tags,
and the final pass gets us the current value of HEAD to initialize
the default branch.
If the source repository is on the local disk we try to use a
hardlink to connect the objects into the new clone as this can
be many times faster than copying the objects or packing them and
passing the data through a pipe to index-pack. Unlike git-clone
we stick to pure Tcl [file link -hard] operation thus avoiding the
need to fork a cpio process to setup the hardlinks. If hardlinks
do not appear to be supported (e.g. filesystem doesn't allow them or
we are crossing filesystem boundaries) we use file copying instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
My guess is, around this time period (Sept. 2007) git-clone was
actually git-clone.sh (Yup, it was built-in in 8434c2f1afed "Build
in clone" Apr 2008). Clone on Cygwin through git-clone.sh was very
slow compared to clone in Tcl using a native Win32 wish process...
Today with git-clone in C, this is a WTF. But at the time, it was
a nice performance boost on the Windows platform. And nobody has
tried to clean this up yet in git-gui.
Yay. My point about commit messages is still valid. :-)
--
Shawn.
^ permalink raw reply
* Re: extra headers in commit objects
From: Sverre Rabbelier @ 2010-02-03 19:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Jelmer Vernooij, Jelmer Vernooij
In-Reply-To: <20100203174041.GC14799@spearce.org>
Heya,
[+cc Jelmer]
On Wed, Feb 3, 2010 at 18:40, Shawn O. Pearce <spearce@spearce.org> wrote:
> I haven't spoken with Jelmer Vernooij directly about it, but after
> some indirect email through a 3rd party, it seems he might be under
> the impression that this really is a bug in Dulwich, because "other
> git implementations do it".
That would seem like the #1 thing to do, I'm sure Jelmer (cc-ed) can
both benefit from this discussion, and perhaps explain what is going
on from first hand. Full thread as it's developing can be found here
[0]. Jelmer, you can just reply to this, no need to subscribe or such.
Also, it's custom on the git list to cc all involved, so you should be
in on the conversation for any emails that are a reply to mine.
[0] http://thread.gmane.org/gmane.comp.version-control.git/138848
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git gui spanish translation.
From: Wincent Colaiuta @ 2010-02-03 19:13 UTC (permalink / raw)
To: "Alejandro Riveira Fernández (by way of Alejandro Riveira Fernández <ariveira@gmail.com>)"
In-Reply-To: <4b69946c.0f67f10a.25e8.03e1@mx.google.com>
Great work on the patch Alejandro. Such a lot of text to translate!
I spotted quite a few spelling errors in it which I comment on below.
There were some style issues as well but nothing too major so I mostly
just commented on the spelling.
El 01/02/2010, a las 20:51, Alejandro Riveira Fernández (by way of
Alejandro Riveira Fernández <ariveira@gmail.com>) escribió:
> +#: git-gui.sh:41 git-gui.sh:737 git-gui.sh:751 git-gui.sh:764 git-
> gui.sh:847
> +#: git-gui.sh:866
> +msgid "git-gui: fatal error"
> +msgstr "git-gui: erro fatal"
erro -> error
> +#: git-gui.sh:738
> +msgid "Cannot find git in PATH."
> +msgstr "git no se encontra en PATH."
encontra -> encuentra
> +"No se puede determinar la version de Git,\n"
> +"\n"
> +"%s dice que es la version '%s',\n"
> +"\n"
> +"%s requeire al menos Git 1.5.0 o superior.\n"
> +"\n"
> +"Asumir que '%s' es versión 1.5.0.?\n"
requeire -> requiere
> +#: git-gui.sh:1835
> +msgid "Staged for removal"
> +msgstr "Preparado para borrar"
> +
> +#: git-gui.sh:1836
> +msgid "Staged for removal, still present"
> +msgstr "Preparado para borrado, todavía presente"
Consistency fix: use either "borrar" in both of the above, or "borrado".
> +#: git-gui.sh:2495 git-gui.sh:3087
> +msgid "Show More Context"
> +msgstr "Mostar mas contexto"
mas -> más
> +#: git-gui.sh:2611
> +msgid "Online Documentation"
> +msgstr "Documentacion en linea"
Documentacion -> Documentación
> +#: git-gui.sh:3315
> +#, tcl-format
> +msgid ""
> +"Possible environment issues exist.\n"
> +"\n"
> +"The following environment variables are probably\n"
> +"going to be ignored by any Git subprocess run\n"
> +"by %s:\n"
> +"\n"
> +msgstr ""
> +"Hay probablemente problemas con las variables de entorno.\n"
> +"\n"
> +"Las sigientes variables de entorno serán probablemente\n"
> +"ignoradas por los todos subprocesos Git ejecutados por\n"
> +"%s:\n"
> +"\n"
"por los todos" doesn't make any sense
perhaps you meant: "por todos los"
> +#: lib/blame.tcl:967
> +msgid "Committer:"
> +msgstr "Comitter:"
"Comitter" (one "m") doesn't exist in Spanish.
Did you mean to leave it as "Committer" (two "m") as in English?
> +#: lib/branch_create.tcl:80
> +msgid "Fast Forward Only"
> +msgstr "Solo Fast Forward"
Solo -> Sólo
> +#: lib/branch_create.tcl:97
> +msgid "Checkout After Creation"
> +msgstr "Activar despues de crear"
despues -> después
> +#: lib/browser.tcl:267 lib/browser.tcl:273
> +msgid "Browse Branch Files"
> +msgstr "Explora los ficheros de la rama"
Explora -> Explorar
You need to use the infinitive consistently for command verbs. You are
doing it in some places but not in others.
> +#: lib/browser.tcl:278 lib/choose_repository.tcl:394
> +#: lib/choose_repository.tcl:480 lib/choose_repository.tcl:491
> +#: lib/choose_repository.tcl:995
> +msgid "Browse"
> +msgstr "Explora"
Explora -> Explorar
> +#: lib/choose_font.tcl:39
> +msgid "Select"
> +msgstr "Selecciona"
Selecciona -> Seleccionar
> +#: lib/choose_repository.tcl:508
> +msgid "Full Copy (Slower, Redundant Backup)"
> +msgstr "Copia completa (Mas lento, redundante, copia de respaldo)"
Mas -> Más
> +#: lib/choose_repository.tcl:586
> +msgid "Standard only available for local repository."
> +msgstr "Standar solo disponible para repositorios locales."
solo -> sólo
> +#: lib/choose_repository.tcl:852
> +msgid "Cannot fetch branches and objects. See console output for
> details."
> +msgstr "Imposible traer las ramas y objetos. Para mas detalles vea
> la salida de consola"
Style issue here... Do you think "obtener" might be a better
translation than "traer" here (and in the other places where you are
translating "fetch")?
Traer is closer to "bring", imo.
> +#: lib/choose_repository.tcl:887
> +msgid "Cannot determine HEAD. See console output for details."
> +msgstr "No se puede determinar HEAD. Para mas detalles vea la
> salida de consola."
mas -> más
> +#: lib/choose_repository.tcl:909
> +msgid "No default branch obtained."
> +msgstr "No se obtubo la rama por defecto."
obtubo -> obtuvo
> +#: lib/choose_rev.tcl:60
> +msgid "Revision Expression:"
> +msgstr "Expresion de revisión:"
Expresion -> Expresión
> +#: lib/choose_rev.tcl:346
> +msgid "Revision expression is empty."
> +msgstr "Exprasión de revisión vacia."
Exprasión -> Expresión
vacia -> vacía
> +#: lib/commit.tcl:18
> +msgid ""
> +"Cannot amend while merging.\n"
> +"\n"
> +"You are currently in the middle of a merge that has not been fully "
> +"completed. You cannot amend the prior commit unless you first
> abort the "
> +"current merge activity.\n"
> +msgstr ""
> +"No se puede corregir mientras durante una fusión.\n"
> +"\n"
> +"Esta usted en el medio de un proceso de fusión que no ha\n"
> +"sido completado. No puede corregir la revision anterior a\n"
> +"no ser que primero cancele el proceso de fusión.\n"
mientras durante -> durante
> +#: lib/commit.tcl:331
> +msgid ""
> +"No changes to commit.\n"
> +"\n"
> +"No files were modified by this commit and it was not a merge
> commit.\n"
> +"\n"
> +"A rescan will be automatically started now.\n"
> +msgstr ""
> +"No hay cambios para una nueva revisión.\n"
> +"\n"
> +"Ningún fihero ha sido modificado por esta revisión y no es una\n"
> +"revisón de fusión.\n"
> +"\n"
> +"Un rescaneo empezará automaticamente ahora.\n"
fihero -> fichero
revisón -> revisión
> +#: lib/date.tcl:25
> +#, tcl-format
> +msgid "Invalid date from Git: %s"
> +msgstr "Fecha invalida de Git: %s"
invalida -> inválida
> +#: lib/merge.tcl:55
> +#, tcl-format
> +msgid ""
> +"You are in the middle of a change.\n"
> +"\n"
> +"File %s is modified.\n"
> +"\n"
> +"You should complete the current commit before starting a merge.
> Doing so "
> +"will help you abort a failed merge, should the need arise.\n"
> +msgstr ""
> +"Esta en el medio de un cambio.\n"
> +"\n"
> +"El fichero %s ha sido modificado.\n"
> +"\n"
> +"Debería completar la revisión actual antes de comenzar la fusión.\n"
> +"Hacer eso le ayudará a cancelar una fusión fallida si surgiese la
> \n"
> +"necesidad.\n"
Esta -> Está
fallida -> fallada
> +#: lib/mergetool.tcl:14
> +#, tcl-format
> +msgid ""
> +"Note that the diff shows only conflicting changes.\n"
> +"\n"
> +"%s will be overwritten.\n"
> +"\n"
> +"This operation can be undone only by restarting the merge."
> +msgstr ""
> +"Tenga en cuenta que el diff solo mestra los cambios conflictivos.\n"
> +"\n"
> +"%s será sobrescrito.\n"
> +"\n"
> +"Esta operacion solo se puede deshacer reiniciando la fusión."
Earlier you used "parche" as a translation for "diff". Perhaps you
should use it here as well.
In any case:
solo -> sólo
mestra -> muestra
solo -> sólo
> +#: lib/option.tcl:149
> +msgid "Blame Copy Only On Changed Files"
> +msgstr "Detección de copia solo a ficheros cambiados"
solo -> sólo
Perhaps also:
a -> en
> +#: lib/option.tcl:151
> +msgid "Blame History Context Radius (days)"
> +msgstr "Contexto de Cronología de Anotación (dias)"
dias -> días
> +#: lib/option.tcl:152
> +msgid "Number of Diff Context Lines"
> +msgstr "Número lineas de contexto en diffs"
"Número de líneas"
Again, use "parches" for "diffs"?
> +#: lib/remote_branch_delete.tcl:109
> +msgid "Delete Only If"
> +msgstr "Borrar solo si"
solo -> sólo
> +#: lib/remote_branch_delete.tcl:184
> +#, tcl-format
> +msgid ""
> +"The following branches are not completely merged into %s:\n"
> +"\n"
> +" - %s"
> +msgstr ""
> +"Las siguientes ramas no estan completamente fusionadas a %s:\n"
> +"\n"
> +"- %s"
estan -> están
> +#: lib/remote_branch_delete.tcl:189
> +#, tcl-format
> +msgid ""
> +"One or more of the merge tests failed because you have not fetched
> the "
> +"necessary commits. Try fetching from %s first."
> +msgstr ""
> +"Una o mas de las comprobaciones de fusión fallaron porque no se
> trajeron las\n"
> +"revisones necesarias. Intente trayendolas de %s primero."
Don't you think:
trayendolas -> traerlas
Would be better?
> +#: lib/remote_branch_delete.tcl:207
> +msgid "Please select one or more branches to delete."
> +msgstr "Por favor seleccione una o mas ramas para borrar."
mas -> más
> +#: lib/remote_branch_delete.tcl:286
> +msgid "No repository selected."
> +msgstr "No se a seleccionado un repositorio."
a -> ha
> +#: lib/search.tcl:25
> +msgid "Case-Sensitive"
> +msgstr "Sensible a Mayusculas"
Mayusculas -> Mayúsculas
> +#: lib/spellcheck.tcl:68
> +msgid "Invalid spell checking configuration"
> +msgstr "Configuraciónn de corrección ortográfica inválida"
Configuraciónn -> Configuración
> +#: lib/spellcheck.tcl:388
> +msgid "Unexpected EOF from spell checker"
> +msgstr "EOF inesperado desde el corrector ortográfico"
I'm not sure what the standard translation of EOF is, but seeing as it
stands for "End Of File" it wouldn't surprise me if there is something
similar in Spanish like "FDA" (Fin De Archivo) or something similar...?
> +#: lib/sshkey.tcl:118
> +msgid "Generation succeded, but no keys found."
> +msgstr "La generación tubo éxito, pero no se encontraron llaves."
tubo -> tuvo
> +#: lib/transport.tcl:175
> +msgid "Use thin pack (for slow network connections)"
> +msgstr "Usar paquete ligero (thin pack) (para conexiones de red
> lentas)"
Don't think you need "thin pack" here.
Cheers,
Wincent
^ permalink raw reply
* Re: [BUG] - "git commit --amend" commits, when exiting the editor with no changes written
From: Avery Pennarun @ 2010-02-03 19:54 UTC (permalink / raw)
To: Eugene Sajine
Cc: Wincent Colaiuta, Matthieu Moy, kusmabite, Johannes Schindelin,
Jacob Helwig, git
In-Reply-To: <76c5b8581002031127m31c39dbbkc7c31d19e4d5874@mail.gmail.com>
On Wed, Feb 3, 2010 at 2:27 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> To reiterate what I said earlier: the mtime idea isn't even
>> automatically a bad one. It's about as good as what currently exists,
>> and the resulting rule (file content or mtime must be modified) is
>> just as consistent as the current rule (file must be nonempty). It's
>> also arguably easier for new users to understand.
>
> OK. Agree on that.
>
>> But you can't just blindly change the system to always work in a
>> different way. People depend on the current behaviour.
>
> I understand that pretty well. My logic is that the most used command
> which is affecting the three is "git commit", therefore this command
> workflow is pretty natural for all users, but the workflow of commit
> --amend and rebase -i which are also affecting the three is
> inconsistent with commit. The user interaction is not the same.
You can't agree with my first statement above and yet still call the
commit --amend behaviour inconsistent with normal commit behaviour.
It is 100% consistent, as others have already pointed out. Whether it
is consistent is not the problem. Your insistence on that point is
what's making people argue with you and is undermining your real
point.
Have fun,
Avery
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Nicolas Pitre @ 2010-02-03 19:53 UTC (permalink / raw)
To: Ron Garret; +Cc: git
In-Reply-To: <ron1-5F71CB.11234903022010@news.gmane.org>
On Wed, 3 Feb 2010, Ron Garret wrote:
> So... how *does* git decide when two blobs are different blobs and when
> they are the same blob with mods? I asked this question before and was
> pointed to the diffcore docs, but that didn't really clear things up.
> That just describes all the different ways git can do diffs, not the
> actual heuristics that git uses to track content.
Yes, those same heuristics are used to make the decision.
|The second transformation in the chain is diffcore-break, and is
|controlled by the -B option to the 'git diff-{asterisk}' commands.
|This is used to detect a filepair that represents "complete rewrite"
|and break such filepair into two filepairs that represent delete and
|create.
|[...]
|This transformation is used to detect renames and copies, and is
|controlled by the -M option (to detect renames) and the -C option
|(to detect copies as well) to the 'git diff-{asterisk}' commands.
|[...]
Note that you may use the -B, -C, -M and --find-copies-harder arguments
with log as well as diff commands even if there is no actual diff
output. So the explanation is really in that document even if simple
rename detection is concerned only by a fraction of what is said there.
And Git can detect copied files too.
Those semantics are not stored in the repository so they can be improved
or even changed after the facts.
Nicolas
^ permalink raw reply
* Re: extra headers in commit objects
From: Scott Chacon @ 2010-02-03 19:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20100203174041.GC14799@spearce.org>
Hey,
On Wed, Feb 3, 2010 at 9:40 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Today I came across this "bug fix" [1,2] in Dulwich, which is
> claiming to be a pure-Python implementation of Git.
>
> I haven't spoken with Jelmer Vernooij directly about it, but after
> some indirect email through a 3rd party, it seems he might be under
> the impression that this really is a bug in Dulwich, because "other
> git implementations do it".
At the risk of pissing you off for the second time in as many days,
this is entirely my fault. I was having a beer with Jelmer in
Wellington a few weeks ago during LinuxConf.au and we were talking
about the difficulties in storing metadata having to do with cross-vcs
migrations - specifically his work with an bzr-git bridge and mine
with the hg-git project. He was noting that I kept all my metadata
about original Hg commits in Git as formatted text in the commit
message, which is pretty uggo (especially with the amount of sometimes
inconsistent denormalization of data Hg does on commit, explicitly
recording renames and manifests and whatnot).
Anyhow, I was saying that _technically_ you can artificially write
extra headers into the commit object (though at the time Dulwich
didn't support reading them because of how it parsed commit objects -
I believe it would actually explode if it saw something it didn't
expect). I said I was still going to keep the metadata in my
implementation in the message, but he was very interested in hiding
his in the commit headers. To my defense, we (you and I, Shawn)
talked about this at the GitTogether this year and you and a few
others told me that CGit would not blow up but would just ignore them,
which is fine for his purposes. I certainly did not get the
impression from that short discussion that this was something to be
absolutely avoided, but rather that it just wasn't really encouraged
or explicitly supported.
Oddly enough, this whole thing basically came up because we were
noting that you can hide extra data in Hg changesets, but it's a
ridiculous hack involving adding it after a null byte in the timestamp
field, much like we do in adding the capabilities after the first ref
in the negotiation phase of the tranfer protocol. I was just casually
saying, "yeah, you can actually technically do that a lot cleaner in
Git"...
Sorry. So, for future reference, though CGit _can_ handle it, don't?
thanks,
Scott
^ permalink raw reply
* Re: extra headers in commit objects
From: Nicolas Pitre @ 2010-02-03 20:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: demerphq, Shawn O. Pearce, git
In-Reply-To: <20100203192658.GP9553@machine.or.cz>
On Wed, 3 Feb 2010, Petr Baudis wrote:
> On Wed, Feb 03, 2010 at 08:01:17PM +0100, demerphq wrote:
> > Shouldn't an old git just ignore headers from a new git?
> >
> > I mean, forget about the fact that somebody is doing something naughty
> > with the git protocol, ask youself if you want this rule to basically
> > prevent any backwards compatible changes with older gits.
>
> We have done similar changes in the past and if there would be such
> a change, we can phase-in it over the course of several releases.
> I think the fall-out would not be that bad; we have some experience
> with even making Debian-stable Git compatible with new stuff. ;-)
Heh... That's because I was crazy enough to do that work so the new
features I implemented in the latest version could be enabled by default
sooner. And incidentally those features weren't controvertial at all
which sorta helped.
Nicolas
^ permalink raw reply
* Re: [PATCH] git gui spanish translation.
From: Alejandro Riveira Fernández @ 2010-02-03 20:04 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <F0288AB4-A1C8-4D72-BA2F-B35B0FDE4180@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
El mié, 03-02-2010 a las 20:13 +0100, Wincent Colaiuta escribió:
> Great work on the patch Alejandro. Such a lot of text to translate!
>
> I spotted quite a few spelling errors in it which I comment on below.
> There were some style issues as well but nothing too major so I mostly
> just commented on the spelling.
>
Will take a look at the things you mention. Thanks for the time to
review it
[-- Attachment #2: Esto es una parte de mensaje firmado digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Pete Harlan @ 2010-02-03 20:12 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Ron Garret, git
In-Reply-To: <32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com>
On 02/03/2010 10:48 AM, Avery Pennarun wrote:
>> [ron@mickey:~/devel/gittest]$ git mv file2 file3
>> [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
>> [master ae3f6d4] letters->numbers
>> 1 files changed, 0 insertions(+), 0 deletions(-)
>> rename file2 => file3 (100%)
>
> Whoops. You didn't 'git add file2' (before the mv) or 'git add file3'
> (after the mv), or use commit -a, so what you've committed is the
> *old* content of file2 under the name file3. The *new* content of
> file2 is still uncommitted in your work tree under the name file3.
It may be reasonable for "git mv foo bar" to print a helpful message to
the user if foo has un-checked-in changes, similarly to what "git rm" does.
Unlike "git rm", "git mv" could still perform the operation even without
"-f", but the semantics of "git mv" differ enough from plain "mv" that a
short blurb from Git in that case might help.
--Pete
^ permalink raw reply
* [gitolite] repo config for delegated projects
From: martin f krafft @ 2010-02-03 20:22 UTC (permalink / raw)
To: git discussion list; +Cc: Sitaram Chamarty, Teemu Matilainen
In-Reply-To: <2e24e5b91002022222h5ca3ebe6k75854a9a056f0ed1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
Dear Sitaram, dear Teemo, dear gitolite-fans,
src/gl-compile-conf:261 prohibits delegated repositories to make use
of the functionality to configure config variables of the
repositories:
die "$WARN $fragment attempting to set repo configuration\n"
if $fragment ne 'master';
This is a bit unfortunate and makes me reconsider the use of
delegations.
What is the reason for this restriction?
Are there settings that are potentially compromising?
Would it be worth to consider making it configurable (e.g.
~/.gitolite.rc) whether to allow delegated repos to set config
variables?
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"there are two major products that come out of berkeley: lsd and unix."
one caused me an addiction
-- fyodor
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Ron Garret @ 2010-02-03 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.1002031436490.1681@xanadu.home>
In article <alpine.LFD.2.00.1002031436490.1681@xanadu.home>,
Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 3 Feb 2010, Ron Garret wrote:
>
> > So... how *does* git decide when two blobs are different blobs and when
> > they are the same blob with mods? I asked this question before and was
> > pointed to the diffcore docs, but that didn't really clear things up.
> > That just describes all the different ways git can do diffs, not the
> > actual heuristics that git uses to track content.
>
> Yes, those same heuristics are used to make the decision.
>
> |The second transformation in the chain is diffcore-break, and is
> |controlled by the -B option to the 'git diff-{asterisk}' commands.
> |This is used to detect a filepair that represents "complete rewrite"
> |and break such filepair into two filepairs that represent delete and
> |create.
> |[...]
>
> |This transformation is used to detect renames and copies, and is
> |controlled by the -M option (to detect renames) and the -C option
> |(to detect copies as well) to the 'git diff-{asterisk}' commands.
> |[...]
>
> Note that you may use the -B, -C, -M and --find-copies-harder arguments
> with log as well as diff commands even if there is no actual diff
> output. So the explanation is really in that document even if simple
> rename detection is concerned only by a fraction of what is said there.
>
> And Git can detect copied files too.
>
> Those semantics are not stored in the repository so they can be improved
> or even changed after the facts.
OK, on closer reading I see that the information is there, but it's well
hidden :-) (For example, the -M option takes an optional numerical
argument so you can tweak how much similarity is needed to be considered
a move. But the docs for git log don't mention this. It's buried deep
in the git diffcore docs. But yes, it's there.)
So I think I'm beginning to understand how this works, but that leads me
to another question: it seems to me that there are potential screw cases
for this purely content-based system of tracking files. For example,
suppose I have a directory full of sample config files, all of which are
similar to each other. Will that cause diffcore to get confused?
Feel free to treat that as a rhetorical question because obviously I can
(and probably should) get the answer by trying it.
Thanks!
rg
^ permalink raw reply
* Re: extra headers in commit objects
From: Shawn O. Pearce @ 2010-02-03 20:31 UTC (permalink / raw)
To: demerphq; +Cc: Petr Baudis, Nicolas Pitre, git
In-Reply-To: <9b18b3111002031143h63aaa6bpa4c91d140a769bb0@mail.gmail.com>
demerphq <demerphq@gmail.com> wrote:
> On 3 February 2010 20:26, Petr Baudis <pasky@suse.cz> wrote:
> Right. The only solution i can see would have had to have been
> implemented already. And that would involved some headers being marked
> "pass through", some "marked throw away on cherry-pick" and some
> "choke horribly if you find this and dont know what it is".
>
> And even with somethng like that one wonders if notes arent really a
> better alternative to user defined headers anyway?
Yes, exactly.
I think notes turn out to be a much better way to store this extra
data, provided you are OK with them being disconnected during an
amend, cherry-pick, filter-branch, or rebase... :-)
And unlike additional headers, git implementations will likely
support notes, because they are a good way to attach additional
user data onto commits.
--
Shawn.
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Ron Garret @ 2010-02-03 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <4B69D897.2060908@pcharlan.com>
In article <4B69D897.2060908@pcharlan.com>,
Pete Harlan <pgit@pcharlan.com> wrote:
> On 02/03/2010 10:48 AM, Avery Pennarun wrote:
> >> [ron@mickey:~/devel/gittest]$ git mv file2 file3
> >> [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
> >> [master ae3f6d4] letters->numbers
> >> 1 files changed, 0 insertions(+), 0 deletions(-)
> >> rename file2 => file3 (100%)
> >
> > Whoops. You didn't 'git add file2' (before the mv) or 'git add file3'
> > (after the mv), or use commit -a, so what you've committed is the
> > *old* content of file2 under the name file3. The *new* content of
> > file2 is still uncommitted in your work tree under the name file3.
>
> It may be reasonable for "git mv foo bar" to print a helpful message to
> the user if foo has un-checked-in changes, similarly to what "git rm" does.
>
> Unlike "git rm", "git mv" could still perform the operation even without
> "-f", but the semantics of "git mv" differ enough from plain "mv" that a
> short blurb from Git in that case might help.
I think that a simple tweak to the docs would be enough. Right now it
says:
"The index is updated after successful completion, but the change must
still be committed."
I'm pretty sure I would have been less confused if it had said something
like:
"The index is updated to reflect the new name of the file, but NOT any
new content that file may contain. Changed content must be added to the
index separately with git add, and all changes must still be commited."
rg
^ permalink raw reply
* Re: git-mv redux: there must be something else going on
From: Ron Garret @ 2010-02-03 20:30 UTC (permalink / raw)
To: git
In-Reply-To: <32541b131002031147r367ee08fxc64c4c54165953a3@mail.gmail.com>
In article
<32541b131002031147r367ee08fxc64c4c54165953a3@mail.gmail.com>,
Avery Pennarun <apenwarr@gmail.com> wrote:
> On Wed, Feb 3, 2010 at 2:23 PM, Ron Garret <ron1@flownet.com> wrote:
> > In article
> > Ah. That explains everything. Thanks. (I thought git mv was
> > equivalent to git rm followed by git add. But it's not.)
>
> I suppose in this case it's not. The only difference is when your
> work tree differs from your index, though, and it's to be expected
> that 'git rm', in removing things from the index, would lose your
> ability to track those differences.
>
> > So... how *does* git decide when two blobs are different blobs and when
> > they are the same blob with mods? I asked this question before and was
> > pointed to the diffcore docs, but that didn't really clear things up.
> > That just describes all the different ways git can do diffs, not the
> > actual heuristics that git uses to track content.
>
> If you really want to know the details, looking at the code really is
> probably the best solution; it's not even that long.
>
> The short version is that git chooses a set of candidate blobs, then
> diffs them and figures out a percentage similarity between each pair.
> (A simple way to think of the similarity index is "how long is the
> diff compared to the file itself?" If the diff is of length zero, the
> similarity is 100%, and so on.) If the similarity is greater than a
> certain threshold, then it's considered to be the same file.
>
> Choosing the set of candidates is actually the more interesting
> problem, since detecting moves using the above algorithm is O(n^2)
> with the number of candidates. That's why 'git diff' and 'git log'
> don't do it at all by default.
>
> If you provide -M, the set of candidates is the set of files that were
> removed/modified and the set of files that were added. (Added files
> are compared against removed/modified files, iirc.) Normally that's a
> very short list. With -C, you need to compare all
> added/removed/modified files with all others, which is slightly more
> work. With --find-copies-harder, it becomes potentially a *lot* of
> work.
Thanks! That clarifies a lot.
rg
^ permalink raw reply
* Re: [PATCH] git gui spanish translation.
From: Alejandro Riveira Fernández @ 2010-02-03 20:37 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <F0288AB4-A1C8-4D72-BA2F-B35B0FDE4180@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]
El mié, 03-02-2010 a las 20:13 +0100, Wincent Colaiuta escribió:
Comments
>
> > +#: lib/branch_create.tcl:80
> > +msgid "Fast Forward Only"
> > +msgstr "Solo Fast Forward"
>
> Solo -> Sólo
You only have to use sólo in case there is the posibility of
missanderstand it. Does not aply here or anywhere else in the
patch
>
> > +#: lib/browser.tcl:267 lib/browser.tcl:273
> > +msgid "Browse Branch Files"
> > +msgstr "Explora los ficheros de la rama"
>
> Explora -> Explorar
>
> You need to use the infinitive consistently for command verbs. You are
> doing it in some places but not in others.
Changed my mind during the translation about using one of the other ...
>
> Style issue here... Do you think "obtener" might be a better
> translation than "traer" here (and in the other places where you are
> translating "fetch")?
I'm open to sugestions. the same problem with "commit" (either verb or
noun) tracking branch, push ( propagar is ok? ) etc...
Those terms do not have a clear translation to spanish so we are
inventing language here
>
> Traer is closer to "bring", imo.
Ok will ponder
> > +#: lib/merge.tcl:55
> > +#, tcl-format
> > +msgid ""
> > +"You are in the middle of a change.\n"
> > +"\n"
> > +"File %s is modified.\n"
> > +"\n"
> > +"You should complete the current commit before starting a merge.
> > Doing so "
> > +"will help you abort a failed merge, should the need arise.\n"
> > +msgstr ""
> > +"Esta en el medio de un cambio.\n"
> > +"\n"
> > +"El fichero %s ha sido modificado.\n"
> > +"\n"
> > +"Debería completar la revisión actual antes de comenzar la fusión.\n"
> > +"Hacer eso le ayudará a cancelar una fusión fallida si surgiese la
> > \n"
> > +"necesidad.\n"
>
> Esta -> Está
>
> fallida -> fallada
They are equivalent
>
> > +#: lib/remote_branch_delete.tcl:189
> > +#, tcl-format
> > +msgid ""
> > +"One or more of the merge tests failed because you have not fetched
> > the "
> > +"necessary commits. Try fetching from %s first."
> > +msgstr ""
> > +"Una o mas de las comprobaciones de fusión fallaron porque no se
> > trajeron las\n"
> > +"revisones necesarias. Intente trayendolas de %s primero."
>
> Don't you think:
>
> trayendolas -> traerlas
Ok
> > +#: lib/spellcheck.tcl:388
> > +msgid "Unexpected EOF from spell checker"
> > +msgstr "EOF inesperado desde el corrector ortográfico"
>
> I'm not sure what the standard translation of EOF is, but seeing as it
> stands for "End Of File" it wouldn't surprise me if there is something
> similar in Spanish like "FDA" (Fin De Archivo) or something similar...?
I think people use the EOF just like they use NULL or cd-rom or many
other neologism
> > +#: lib/transport.tcl:175
> > +msgid "Use thin pack (for slow network connections)"
> > +msgstr "Usar paquete ligero (thin pack) (para conexiones de red
> > lentas)"
>
> Don't think you need "thin pack" here.
Well believe my first translation had many other terms in both
English and Spanish. I feared to just create confusion translating
everything (because there are no docs in spanish)
>
> Cheers,
> Wincent
>
>
>
[-- Attachment #2: Esto es una parte de mensaje firmado digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Using "git log" to find the files patched at the same time as a named file
From: Zack Brown @ 2010-02-03 20:38 UTC (permalink / raw)
To: git
Hi folks,
If I have a filename I'm interested in, and I want to find other files
that have been modified in the same commits that modified the file I'm
interested in, how could I do that with git?
If I give the command
$ git log --name-only
then the bottom of each log entry will list all the files that were
modified by that commit. That's basically what I want, except that the
command will list all log entries, not just the ones that modified the
file I'm interested in.
If I give the command
$ git log --name-only fs/fuse/file.c
then the bottom of each log entry only lists fs/fuse/file.c, even if
the very same commit showed up in the output from the previous command
with multiple files in addition to that one. In other words, the "git
log --name-only fs/fuse/file.c" command will only list fs/fuse/file.c
as being changed, in commits that I know changed more than just that
one file.
Is there a git command that will run in roughly the same amount of
time as the ones given above (i.e. with only a single invocation of
git), but that will only output the commits that affected the file I'm
interested in, and that will also list any other files changed in
those same commits?
Many thanks,
Zack
--
Zack Brown
^ 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