[parent not found: <7veifxe63j.fsf@alter.siamese.dyndns.org>]
* Re: [PATCH] bash completion: Support "divergence from upstream" messages in __git_ps1
[not found] ` <7veifxe63j.fsf@alter.siamese.dyndns.org>
@ 2010-06-23 22:54 ` Shawn O. Pearce
0 siblings, 0 replies; 24+ messages in thread
From: Shawn O. Pearce @ 2010-06-23 22:54 UTC (permalink / raw)
To: Junio C Hamano, Andrew Sayers; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
>
> * tr/rev-list-count (2010-06-17) 2 commits
> - bash completion: Support "divergence from upstream" messages in __git_ps1
> - rev-list: introduce --count option
>
> I'd like an Ack/Nack on the tip one from people involved in the completion
> scripts.
Tip commit Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
[not found] ` <7veifxe63j.fsf@alter.siamese.dyndns.org>
@ 2010-06-23 23:21 ` Ævar Arnfjörð Bjarmason
2010-06-24 0:44 ` Nazri Ramliy
` (6 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2010-06-23 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Jun 23, 2010 at 22:09, Junio C Hamano <gitster@pobox.com> wrote:
> * ab/i18n (2010-06-15) 3 commits
> . Add initial C, Shell and Perl gettext translations
> . fixup! Add infrastructure
> . Add infrastructure for translating Git with gettext
>
> The parts that touch other topics in flight probably need to be split into
> separate patches; otherwise it is unmanageable.
I've just submitted "[PATCH v5] Add infrastructure for translating Git
with gettext" (<1277332338-8486-1-git-send-email-avarab@gmail.com>)
that omits the "Add initial C, Shell and Perl gettext translations"
patch. This'll greatly ease merging it with other topics.
I can split it up further if you want, perhaps you'd like the changes
to the Makefile to be in one seperate patch? Although I don't see how
that makes it easier to merge since you'd have to solve that conflict
anyway, but perhaps your workflow is different from mine.
Tell me if I can do anything else to make it easier to merge it.
> * ab/tap (2010-06-15) 5 commits
> . TAP: Make sure there's a newline before "ok" under harness
> . TAP: Say "pass" rather than "ok" on an empty line
> . We use TAP so the Perl test can run without scaffolding
> . Skip tests in a way that makes sense under TAP
> . Make test-lib.sh emit valid TAP format
>
> Updated with a newer round but it seems to break "make -j8 test" when
> merged to 'pu', hence ejected.
How does it break under pu? I can't see any suspicious behavior when
running it. I've run it with -j1 and -j8 in both next and pu and I get
the same test test-results/ every time.
> I was not sure why TAP is worth the trouble, and I still am not
> sure.
Covered in comments to a previous "What's cooking" post.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
[not found] ` <7veifxe63j.fsf@alter.siamese.dyndns.org>
2010-06-23 23:21 ` What's cooking in git.git (Jun 2010, #04; Wed, 23) Ævar Arnfjörð Bjarmason
@ 2010-06-24 0:44 ` Nazri Ramliy
2010-06-24 3:46 ` Tay Ray Chuan
` (5 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Nazri Ramliy @ 2010-06-24 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Thu, Jun 24, 2010 at 6:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [New Topics]
>
> * ar/decorate-color (2010-06-23) 4 commits
> - Allow customizable commit decorations colors
This commit has some style violations. I've just sent a replacement patch, with
an explanation of (and an apology for) the offences [1].
nazri
[1] http://mid.gmane.org/1277338876-21958-1-git-send-email-ayiehere@gmail.com
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
` (2 preceding siblings ...)
2010-06-24 0:44 ` Nazri Ramliy
@ 2010-06-24 3:46 ` Tay Ray Chuan
2010-06-24 11:17 ` Finn Arne Gangstad
` (4 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Tay Ray Chuan @ 2010-06-24 3:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Thu, Jun 24, 2010 at 6:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [snip]
> * tc/maint-checkout-f-b (2010-06-21) 3 commits
> - builtin/checkout: Fix -f used with -b
> - t2018-checkout-branch.sh: "checkout -f -b" broken
> - add tests for checkout -b
In case anyone is wondering, this series has been dropped in lieu of
"tc/checkout-B".
--
Cheers,
Ray Chuan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
` (3 preceding siblings ...)
2010-06-24 3:46 ` Tay Ray Chuan
@ 2010-06-24 11:17 ` Finn Arne Gangstad
2010-06-24 11:42 ` Johannes Sixt
2010-06-24 20:21 ` Junio C Hamano
2010-06-24 14:48 ` Johannes Sixt
` (3 subsequent siblings)
8 siblings, 2 replies; 24+ messages in thread
From: Finn Arne Gangstad @ 2010-06-24 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eyvind Bernhardsen, git
On Wed, Jun 23, 2010 at 03:09:32PM -0700, Junio C Hamano wrote:
> * eb/double-convert-before-merge (2010-06-16) 1 commit
> - ll-merge: Normalize files before merging
>
> If running git-to-worktree and then worktree-to-git _fixes_ something, it
> means that these are not roundtrip operations; there is something that is
> fundamentally wrong. The commit log message doesn't help explaining it,
> either.
If .gitattributes is different on the different sides, or if you
enable autocrlf, the current repo contents may change after
git-to-worktree and worktree-to-git again. This is most easily seen if
you add some eol attributes, but also with clean/smudge filters, ident
and so on.
Assume you start out with a repo that has a lot of text files with
CRLF checked in (A).
C----
/ \
A---B---D
B: Add "* text=auto" to .gitattributes and normalize all files to LF
only in repo
D: try to merge C
Without this patch you will get a ridiculous number of lf/crlf
conflicts when trying to merge C into D, since the repository contents
for C are "wrong" wrt the new .gitattributes file.
- Finn Arne
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 11:17 ` Finn Arne Gangstad
@ 2010-06-24 11:42 ` Johannes Sixt
2010-06-24 11:58 ` Finn Arne Gangstad
2010-06-24 12:23 ` Eyvind Bernhardsen
2010-06-24 20:21 ` Junio C Hamano
1 sibling, 2 replies; 24+ messages in thread
From: Johannes Sixt @ 2010-06-24 11:42 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Junio C Hamano, Eyvind Bernhardsen, git
Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
> Assume you start out with a repo that has a lot of text files with
> CRLF checked in (A).
>
> C----
> / \
> A---B---D
>
> B: Add "* text=auto" to .gitattributes and normalize all files to LF
> only in repo
>
> D: try to merge C
>
> Without this patch you will get a ridiculous number of lf/crlf
> conflicts when trying to merge C into D, since the repository contents
> for C are "wrong" wrt the new .gitattributes file.
What should happen when you have C checked out (i.e., you do not yet have
the updated .gitattributes in your worktree nor index) and merge B?
Currently, you get the identical conflicts, but I suspect that the patch
does not help in this situation. IOW, it breaks the merge symmetry.
-- Hannes
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 11:42 ` Johannes Sixt
@ 2010-06-24 11:58 ` Finn Arne Gangstad
2010-06-24 12:23 ` Eyvind Bernhardsen
1 sibling, 0 replies; 24+ messages in thread
From: Finn Arne Gangstad @ 2010-06-24 11:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Eyvind Bernhardsen, git
On Thu, Jun 24, 2010 at 01:42:56PM +0200, Johannes Sixt wrote:
> Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
> > Assume you start out with a repo that has a lot of text files with
> > CRLF checked in (A).
> >
> > C----
> > / \
> > A---B---D
> >
> > B: Add "* text=auto" to .gitattributes and normalize all files to LF
> > only in repo
> >
> > D: try to merge C
> >
> > Without this patch you will get a ridiculous number of lf/crlf
> > conflicts when trying to merge C into D, since the repository contents
> > for C are "wrong" wrt the new .gitattributes file.
>
> What should happen when you have C checked out (i.e., you do not yet have
> the updated .gitattributes in your worktree nor index) and merge B?
> Currently, you get the identical conflicts, but I suspect that the patch
> does not help in this situation. IOW, it breaks the merge symmetry.
git merges .gitattributes early, so it will work any way you do the
merge I think? Each file in a merge is processed separately with
whatever .gitattributes file is active.
If you get a conflict in .gitattributes you may be in a slightly
interesting spot, but you will still get all the new attributes in the
conflicted file, so in practice it should still work. git ignores the
conflict markers in .gitattributes and moves on..
- Finn Arne
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 11:42 ` Johannes Sixt
2010-06-24 11:58 ` Finn Arne Gangstad
@ 2010-06-24 12:23 ` Eyvind Bernhardsen
1 sibling, 0 replies; 24+ messages in thread
From: Eyvind Bernhardsen @ 2010-06-24 12:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Finn Arne Gangstad, Junio C Hamano, git
On 24. juni 2010, at 13.42, Johannes Sixt wrote:
> Am 6/24/2010 13:17, schrieb Finn Arne Gangstad:
>> Assume you start out with a repo that has a lot of text files with
>> CRLF checked in (A).
>>
>> C----
>> / \
>> A---B---D
>>
>> B: Add "* text=auto" to .gitattributes and normalize all files to LF
>> only in repo
>>
>> D: try to merge C
>>
>> Without this patch you will get a ridiculous number of lf/crlf
>> conflicts when trying to merge C into D, since the repository contents
>> for C are "wrong" wrt the new .gitattributes file.
>
> What should happen when you have C checked out (i.e., you do not yet have
> the updated .gitattributes in your worktree nor index) and merge B?
> Currently, you get the identical conflicts, but I suspect that the patch
> does not help in this situation. IOW, it breaks the merge symmetry.
I confess that I didn't expect this to work either, but it does: the merge completes without conflict. This is even covered in the included test script ("Check merging addition of text=auto").
I've cleaned the patch up a bit and added automatic delete/normalize conflict resolution. Will submit a new version soon.
--
Eyvind Bernhardsen
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 11:17 ` Finn Arne Gangstad
2010-06-24 11:42 ` Johannes Sixt
@ 2010-06-24 20:21 ` Junio C Hamano
2010-06-24 20:51 ` Eyvind Bernhardsen
` (2 more replies)
1 sibling, 3 replies; 24+ messages in thread
From: Junio C Hamano @ 2010-06-24 20:21 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Eyvind Bernhardsen, git
Finn Arne Gangstad <finnag@pvv.org> writes:
> On Wed, Jun 23, 2010 at 03:09:32PM -0700, Junio C Hamano wrote:
>
>> * eb/double-convert-before-merge (2010-06-16) 1 commit
>> - ll-merge: Normalize files before merging
>>
>> If running git-to-worktree and then worktree-to-git _fixes_ something, it
>> means that these are not roundtrip operations; there is something that is
>> fundamentally wrong. The commit log message doesn't help explaining it,
>> either.
>
> If .gitattributes is different on the different sides, or if you
> enable autocrlf, the current repo contents may change after
> git-to-worktree and worktree-to-git again.
IOW, g2w-then-w2g may not be an identity function.
If we were to encourage use of this codepath to wider audiences, we may
need to have a document for people who write smudge/clean filters. In
order for the result to be stable, applying g2w-then-w2g once again on top
of the result of running g2w-then-w2g on anything should be no-op, no?
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 20:21 ` Junio C Hamano
@ 2010-06-24 20:51 ` Eyvind Bernhardsen
2010-06-24 22:48 ` Junio C Hamano
2010-06-25 6:02 ` Johannes Sixt
2010-06-25 7:46 ` Finn Arne Gangstad
2 siblings, 1 reply; 24+ messages in thread
From: Eyvind Bernhardsen @ 2010-06-24 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Finn Arne Gangstad, git
On 24. juni 2010, at 22.21, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
>> If .gitattributes is different on the different sides, or if you
>> enable autocrlf, the current repo contents may change after
>> git-to-worktree and worktree-to-git again.
>
> IOW, g2w-then-w2g may not be an identity function.
>
> If we were to encourage use of this codepath to wider audiences, we may
> need to have a document for people who write smudge/clean filters. In
> order for the result to be stable, applying g2w-then-w2g once again on top
> of the result of running g2w-then-w2g on anything should be no-op, no?
Hm. Isn't that already a requirement? If a clean filter doesn't clean to something normalized, simply touching a file could result in spurious differences (much like pre-safe-autocrlf autocrlf). I could well be missing something here, though.
--
Eyvind
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 20:51 ` Eyvind Bernhardsen
@ 2010-06-24 22:48 ` Junio C Hamano
2010-06-25 8:43 ` Finn Arne Gangstad
2010-06-25 19:43 ` Eyvind Bernhardsen
0 siblings, 2 replies; 24+ messages in thread
From: Junio C Hamano @ 2010-06-24 22:48 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Finn Arne Gangstad, git
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
> On 24. juni 2010, at 22.21, Junio C Hamano wrote:
>
>> Finn Arne Gangstad <finnag@pvv.org> writes:
>>
>>> If .gitattributes is different on the different sides, or if you
>>> enable autocrlf, the current repo contents may change after
>>> git-to-worktree and worktree-to-git again.
>>
>> IOW, g2w-then-w2g may not be an identity function.
>>
>> If we were to encourage use of this codepath to wider audiences, we may
>> need to have a document for people who write smudge/clean filters. In
>> order for the result to be stable, applying g2w-then-w2g once again on top
>> of the result of running g2w-then-w2g on anything should be no-op, no?
>
> Hm. Isn't that already a requirement? If a clean filter doesn't clean
> to something normalized, simply touching a file could result in spurious
> differences (much like pre-safe-autocrlf autocrlf). I could well be
> missing something here, though.
A natural expectation would be that g2w-then-w2g is an identity function,
I think. But the "feature" under discussion in this thread depends on
that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).
IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
perform more than just a round-trip but actively _clean things up_, aren't
we? I don't think we have documented that suggestion, and I actually
think we might even have said that g2w-then-w2g should be a no-op
somewhere in the documentation.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 22:48 ` Junio C Hamano
@ 2010-06-25 8:43 ` Finn Arne Gangstad
2010-06-25 19:43 ` Eyvind Bernhardsen
1 sibling, 0 replies; 24+ messages in thread
From: Finn Arne Gangstad @ 2010-06-25 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eyvind Bernhardsen, git
On Thu, Jun 24, 2010 at 03:48:36PM -0700, Junio C Hamano wrote:
> A natural expectation would be that g2w-then-w2g is an identity function,
> I think. But the "feature" under discussion in this thread depends on
> that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).
This is a natural expecation for subsequent runs. The first time you
run it though, it makes more sense (and all built in filters act this
way) to change the file to its canonical form instead. If it already
is in its canonical form, you expect no further change.
> IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
> perform more than just a round-trip but actively _clean things up_, aren't
> we? I don't think we have documented that suggestion, and I actually
> think we might even have said that g2w-then-w2g should be a no-op
> somewhere in the documentation.
It's not that we suggest they should clean things up, it is that they
ALREADY clean things up. It's hard to make a reasonable filter that
doesn't. And git should (and can!) give you some assistance in
handling cleanup-related changes if you have such a filter.
To make a non-normalizing filter, both of these would have to be true:
1. g2w then g2w again would change the file even more
2. w2g on something that was run twice through g2w would be equivalent
to running it through g2w once.. e.g. w2g(g2w(g2w(x))) == g2w(x),
can't think of any resaonable scenario.
If you somehow manage to make a filter where w2g(g2w(x)) == x for all
x, the patch under discussion will not create any problems. I've never
seen such a filter though.
- Finn Arne
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 22:48 ` Junio C Hamano
2010-06-25 8:43 ` Finn Arne Gangstad
@ 2010-06-25 19:43 ` Eyvind Bernhardsen
2010-06-25 21:17 ` Junio C Hamano
1 sibling, 1 reply; 24+ messages in thread
From: Eyvind Bernhardsen @ 2010-06-25 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Finn Arne Gangstad, git
On 25. juni 2010, at 00.48, Junio C Hamano wrote:
> Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
>
>> Hm. Isn't that already a requirement? If a clean filter doesn't clean
>> to something normalized, simply touching a file could result in spurious
>> differences (much like pre-safe-autocrlf autocrlf). I could well be
>> missing something here, though.
>
> A natural expectation would be that g2w-then-w2g is an identity function,
> I think. But the "feature" under discussion in this thread depends on
> that g2w-then-w2g is _not_ a noop (otherwise it wouldn't do us any good).
Well, it assumes that g2w does not smudge already smudged data (or that w2g can clean up after double smudging), but when the assumption fails you end up with the same merge conflict you would get without this series. Is it important that _all_ filters support merging?
> IOW, we are suggesting authors of clean/smudge to make their g2w-then-w2g
> perform more than just a round-trip but actively _clean things up_, aren't
> we? I don't think we have documented that suggestion, and I actually
> think we might even have said that g2w-then-w2g should be a no-op
> somewhere in the documentation.
I think it's worth documenting that a well-written ("normalizing", as Finn Arne said) filter allows automatic merging of filtered and unfiltered data. I'll see what I can come up with.
--
Eyvind
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 20:21 ` Junio C Hamano
2010-06-24 20:51 ` Eyvind Bernhardsen
@ 2010-06-25 6:02 ` Johannes Sixt
2010-06-25 7:46 ` Finn Arne Gangstad
2 siblings, 0 replies; 24+ messages in thread
From: Johannes Sixt @ 2010-06-25 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Finn Arne Gangstad, Eyvind Bernhardsen, git
Am 6/24/2010 22:21, schrieb Junio C Hamano:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>> If .gitattributes is different on the different sides, or if you
>> enable autocrlf, the current repo contents may change after
>> git-to-worktree and worktree-to-git again.
>
> IOW, g2w-then-w2g may not be an identity function.
>
> If we were to encourage use of this codepath to wider audiences, we may
> need to have a document for people who write smudge/clean filters. In
> order for the result to be stable, applying g2w-then-w2g once again on top
> of the result of running g2w-then-w2g on anything should be no-op, no?
I think this is implicit to some degree in the documentation,
gitattributes(5):
The content filtering is done to massage the content into a shape that
is more convenient for the platform, filesystem, and the user to use.
[...] the intent is that if someone unsets the filter driver
definition, or does not have the appropriate filter program, the
project should still be usable.
>From this I read that the content of the repository can only be in a
canonical shape; hence, the only thing that a clean filter can do is to
generate the canonical shape of the data. This is, by definition, an
idempotent operation (i.e., g2w(g2w(x)) == g2w(x)).
(I'm talking only about clean filters because any pair of smudge+clean
filters where the clean filter cannot undo the effect of the smudge filter
would be noticed immediately and be considered broken without being
mentioned explicitly in the documentation.)
-- Hannes
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 20:21 ` Junio C Hamano
2010-06-24 20:51 ` Eyvind Bernhardsen
2010-06-25 6:02 ` Johannes Sixt
@ 2010-06-25 7:46 ` Finn Arne Gangstad
2 siblings, 0 replies; 24+ messages in thread
From: Finn Arne Gangstad @ 2010-06-25 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eyvind Bernhardsen, git
On Thu, Jun 24, 2010 at 01:21:49PM -0700, Junio C Hamano wrote:
> >
> > If .gitattributes is different on the different sides, or if you
> > enable autocrlf, the current repo contents may change after
> > git-to-worktree and worktree-to-git again.
>
> IOW, g2w-then-w2g may not be an identity function.
Absolutely, pretty much by definition this cannot be the case (and is
not the case for any of the built-in filters like eol, autocrlf,
ident), since you have no control of what you have in the repository
before you enable the filter.
What we assume though is that g2w(g2w(x)) == g2w(x). I think it is
very hard to come up with a reasonable case for a filter where that is
not the case.
> If we were to encourage use of this codepath to wider audiences, we may
> need to have a document for people who write smudge/clean filters. In
> order for the result to be stable, applying g2w-then-w2g once again on top
> of the result of running g2w-then-w2g on anything should be no-op, no?
This _has_ to work, otherwise you would get dirty contents after a
checkout, and that would be horrible.
So, the follolwing should be true:
g2w(x) == g2w(g2w(x))
A -> g2w() -> B -> g2w() -> B ...
w2g(g2w(x)) == w2g(g2w(w2g(g2w(x))))
X -> g2w() -> w2g() -> Y -> g2w() -> w2g() -> Y ...
Running w2g() twice should also be the same as running it once.
I thought nothing in git required it as such, but in the case of a
missing smudge filter git will call w2g() on something that is already
cleaned. I think the clean/smudge guidelines should be:
"Both clean and smudge filters should be idempotent; running them
multiple times should not alter the contents further."
- Finn Arne
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
` (4 preceding siblings ...)
2010-06-24 11:17 ` Finn Arne Gangstad
@ 2010-06-24 14:48 ` Johannes Sixt
2010-06-24 15:33 ` git log --objects Holger Hellmuth
2010-06-24 15:41 ` What's cooking in git.git (Jun 2010, #04; Wed, 23) Clément Poulain
2010-06-25 2:27 ` Christian Couder
` (2 subsequent siblings)
8 siblings, 2 replies; 24+ messages in thread
From: Johannes Sixt @ 2010-06-24 14:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Am 6/24/2010 0:09, schrieb Junio C Hamano:
> * cp/textconv-cat-file (2010-06-09) 4 commits
> - [DONTMERGE] git gui: use textconv filter for diff and blame
This git-gui patch needs a fixup.
-- Hannes
diff --git a/git-gui/lib/diff.tcl b/git-gui/lib/diff.tcl
index b02d2e5..c628750 100644
--- a/git-gui/lib/diff.tcl
+++ b/git-gui/lib/diff.tcl
@@ -280,7 +280,7 @@ proc start_show_diff {cont_info {add_opts {}}} {
lappend cmd diff-files
}
}
- if {![is_config_false gui.textconv] && [git-version >ñ.6.1]} {
+ if {![is_config_false gui.textconv] && [git-version >= 1.6.1]} {
lappend cmd --textconv
}
^ permalink raw reply related [flat|nested] 24+ messages in thread* git log --objects
2010-06-24 14:48 ` Johannes Sixt
@ 2010-06-24 15:33 ` Holger Hellmuth
2010-06-25 10:06 ` Santi Béjar
2010-06-24 15:41 ` What's cooking in git.git (Jun 2010, #04; Wed, 23) Clément Poulain
1 sibling, 1 reply; 24+ messages in thread
From: Holger Hellmuth @ 2010-06-24 15:33 UTC (permalink / raw)
To: git
Shouldn't 'git log --objects' print out a list of all objects in the
file tree of the commits it lists?
I tried git log with lots of other parameters, for example '-p' and
never saw any difference to the normal output and definitely no list of
hash ids.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: git log --objects
2010-06-24 15:33 ` git log --objects Holger Hellmuth
@ 2010-06-25 10:06 ` Santi Béjar
0 siblings, 0 replies; 24+ messages in thread
From: Santi Béjar @ 2010-06-25 10:06 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: git
On Thu, Jun 24, 2010 at 5:33 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> Shouldn't 'git log --objects' print out a list of all objects in the
> file tree of the commits it lists?
In fact --objects prints all objects reachable from the given commits
(or between commits if $commit1..$commit2)
>
> I tried git log with lots of other parameters, for example '-p' and
> never saw any difference to the normal output and definitely no list of
> hash ids.
I think --objects, --objects-edge, --unpacked are for "git rev-list".
So they should not be listed in git-log man page.
HTH,
Santi
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-24 14:48 ` Johannes Sixt
2010-06-24 15:33 ` git log --objects Holger Hellmuth
@ 2010-06-24 15:41 ` Clément Poulain
1 sibling, 0 replies; 24+ messages in thread
From: Clément Poulain @ 2010-06-24 15:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
> Am 6/24/2010 0:09, schrieb Junio C Hamano:
>> * cp/textconv-cat-file (2010-06-09) 4 commits
>> - [DONTMERGE] git gui: use textconv filter for diff and blame
>
> This git-gui patch needs a fixup.
I wonder where do this come from.
It's seems to be OK there:
http://mid.gmane.org/1276102929-31712-4-git-send-email-clement.poulain@ensimag.imag.fr
doesn't it ?
Regards
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
` (5 preceding siblings ...)
2010-06-24 14:48 ` Johannes Sixt
@ 2010-06-25 2:27 ` Christian Couder
2010-06-25 10:30 ` Ævar Arnfjörð Bjarmason
2010-06-25 13:43 ` Michael J Gruber
8 siblings, 0 replies; 24+ messages in thread
From: Christian Couder @ 2010-06-25 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
On Thursday 24 June 2010 00:09:32 Junio C Hamano wrote:
>
> * cc/cherry-pick-stdin (2010-06-14) 3 commits
> - revert: do not rebuild argv on heap
> - revert: accept arbitrary rev-list options
> - t3508 (cherry-pick): futureproof against unmerged files
>
> What's the doneness of this one?
With the documentation fix I just posted, I think it is finished.
Thanks,
Christian.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
` (6 preceding siblings ...)
2010-06-25 2:27 ` Christian Couder
@ 2010-06-25 10:30 ` Ævar Arnfjörð Bjarmason
2010-06-25 13:43 ` Michael J Gruber
8 siblings, 0 replies; 24+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2010-06-25 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael J Gruber
On Wed, Jun 23, 2010 at 22:09, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking.
Here are topics that I've submitted that haven't made it into a
"What's cooking" post, but which I consider ready for inclusion.
Since I'm not sure whether they've been rejected, ignored or just
forgotten I'm listing them here. It'd be nice to get an update on
their status so I can act appropriately on my end.
* git-am: Ignore whitespace before patches
(<1273944188-9472-1-git-send-email-avarab@gmail.com>)
Junio commented:
Actually cut-and-paste is often a major source of whitespace breakage
(including tabs silently being expanded), and I personally think a patch
like this to encourage the practice is going in a wrong direction.
my reply:
What it does is enable the GMail -> download -> git-am workflow. GMail
(and doubtless countless other) E-Mail providers introduce whitespace
at the beginning of raw E-Mail messages, while otherwise leaving them
intact.
That patch just makes git-am smarter while harming nothing. Given
the fuzzy behavior of E-Mail programs I think it should be included,
and generally that patch detection should try harder before failing.
* Remove editor-specific droppings from .gitignore
(<1274061883-18043-1-git-send-email-avarab@gmail.com>).
Micro-cleanup that removes the (as far as I can see) only case
where .gitignore isn't ignoring something generated by the build
system. Context:
On Mon, May 17, 2010 at 01:35, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Michael J Gruber wrote:
>
>> Does the git build process call format-patch? No! The .gitignore we
>> distribute is meant for things the build process creates
>
> Ah, true. I seem to remember a thread long ago about whether to
> include editor droppings in .gitignore, but I can’t find it in
> the git or lkml archive.
>
> git’s .gitignore does not include .*.swp, \#*#, *~, indeed.
Thanks both of you, I stand corrected. Anyway, I guess this is a bug
then. It's the only thing ignored by Git's various .gitignore files
that isn't created by the build system.
The patch was acked by Michael J Gruber <git@drmicha.warpmail.net>.
* perl libs: perl -w + use warnings is redundant
(<1274460741-9674-1-git-send-email-avarab@gmail.com>).
A minor cleanup of our Perl code, uses lexical warnings instead of
global warnings in code that's known to require Perl 5.6.0 or
later. Doesn't change behavior but uses the recommended Perl form.
* sha1_file: Show the the type and path to corrupt objects
(<1276174021-9544-1-git-send-email-avarab@gmail.com>).
Make the error message for git-cat-file's (and other blog accessor
functions) more specific. From the commit message:
Change the error message that's displayed when we encounter corrupt
objects to be more specific. We now print the type (loose or packed)
of corrupted objects, along with the full path to the file in
question.
Before:
$ git cat-file blob 909ef997367880aaf2133bafa1f1a71aa28e09df
fatal: object 909ef997367880aaf2133bafa1f1a71aa28e09df is corrupted
After:
$ git cat-file blob 909ef997367880aaf2133bafa1f1a71aa28e09df
fatal: loose object 909ef997367880aaf2133bafa1f1a71aa28e09df
(stored in .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df) is
corrupted
Knowing the path helps to quickly analyze what's wrong:
$ file .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df
.git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df: empty
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)
2010-06-23 22:09 What's cooking in git.git (Jun 2010, #04; Wed, 23) Junio C Hamano
` (7 preceding siblings ...)
2010-06-25 10:30 ` Ævar Arnfjörð Bjarmason
@ 2010-06-25 13:43 ` Michael J Gruber
8 siblings, 0 replies; 24+ messages in thread
From: Michael J Gruber @ 2010-06-25 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano venit, vidit, dixit 24.06.2010 00:09:
>
> * mg/rev-parse-lrbranches-locals (2010-05-14) 1 commit
> - revlist: Introduce --lrbranches and --locals revision specifiers
> (this branch uses mg/rev-parse-option-sifter-deprecation.)
>
> I am reluctant to merge a patch that introduces an unpronounceable
> option.
While I could tell you how to pronounce it, I actually was about to
suggest dropping this patch! I don't like the name lrbranches, we have
two names (heads/branches) for local branch heads already, and couldn't
come up with a better name, available name meaning "all branch heads".
>
> * mg/rev-parse-option-sifter-deprecation (2010-05-14) 3 commits
> - t6018: make sure all tested symbolic names are different revs
> - t6018: add tests for rev-list's --branches and --tags
> - rev-parse: deprecate use as an option sifter
> (this branch is used by mg/rev-parse-lrbranches-locals.)
>
> I don't think these patches help anything. Opinions?
They helped the patch which is going to get dropped...
Besides that: The two test patches improve the tests. t6018 gives the
impression to test something which it doesn't (because some symbolic
names point to the same rev, so it doesn't test whether rev-parse really
resolves all of them), and was lacking coverage for --branches and
--tags. So I think those two are independent improvements.
About the "deprecation/discouragement notice" for rev-parse I don't
know. rev-parse is not completely in sync with all rev-list options, and
doesn't mean to be if I understood correctly. I know that now. As long
as nobody cares, nobody cares...
Cheers,
Michael
^ permalink raw reply [flat|nested] 24+ messages in thread