* Re: [PATCH v5 14/15] fast-export: make sure updated refs get updated
From: Junio C Hamano @ 2012-11-21 18:12 UTC (permalink / raw)
To: Max Horn
Cc: Felipe Contreras, git, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <D39D26A9-16B4-4A9F-9102-BD2C92FA10AF@quendi.de>
Max Horn <max@quendi.de> writes:
> On 11.11.2012, at 14:59, Felipe Contreras wrote:
>
>> When an object has already been exported (and thus is in the marks) it's
>> flagged as SHOWN, so it will not be exported again, even if in a later
>> time it's exported through a different ref.
>>
>> We don't need the object to be exported again, but we want the ref
>> updated, which doesn't happen.
>>
>> Since we can't know if a ref was exported or not, let's just assume that
>> if the commit was marked (flags & SHOWN), the user still wants the ref
>> updated.
>>
>> IOW: If it's specified in the command line, it will get updated,
>> regardless of wihether or not the object was marked.
>
> Typo: wihether => whether
>
>>
>> So:
>>
>> % git branch test master
>> % git fast-export $mark_flags master
>> % git fast-export $mark_flags test
>>
>> Would export 'test' properly.
>>
>> Additionally, this fixes issues with remote helpers; now they can push
>> refs wich objects have already been exported, and a few other issues as
>
> Typo: wich => which
I'd rather use "whose" there.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-11-21 18:14 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <1352642392-28387-16-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> They have been marked as UNINTERESTING for a reason, lets respect that.
> ...
> The current behavior is most certainly not what we want. After this
> patch, nothing gets exported, because nothing was selected (everything
> is UNINTERESTING).
The old behaviour was an incorrect "workaround" that has been
superseded by your 14/15 "make sure updated refs get updated", no?
Mentioning that would help people realize that this patch would not
cause regression on them, I would think.
^ permalink raw reply
* Re: [PATCH v5 11/15] remote-testgit: make clear the 'done' feature
From: Junio C Hamano @ 2012-11-21 18:11 UTC (permalink / raw)
To: Max Horn
Cc: Felipe Contreras, git, Johannes Schindelin, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <EA56F0CC-7C93-491F-A076-4A1AA9593ED0@quendi.de>
Max Horn <max@quendi.de> writes:
> Aha, now I understand what this patch is about. So I would suggest this alternate commit message:
>
> remote-testgit: make it explicit clear that we use the 'done' feature
>
> Previously we relied on passing '--use-done-feature ' to git fast-export, which is
> easy to miss when looking at this script. Since remote-testgit is also a reference
> implementation, we now explicitly output 'feature done' / 'done' to make it
> crystal clear that we implement this feature.
I'd state it like this, but I may have guessed what Felipe intended
incorrectly.
remote-testgit: advertise "done" feature and write "done" ourselves
Instead of letting "fast-export" advertise the feature and ending
its stream with "done", do it ourselves. This way, it would make it
more clear to people who want to write their own remote-helper to
produce fast-export streams without using "fast-export
--use-done-feature" that they are supposed to end their stream with
"done".
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Lisandro Damián Nicanor Pérez Meyer @ 2012-11-21 16:43 UTC (permalink / raw)
To: Holger Hellmuth (IKS); +Cc: Andrew Ardill, git@vger.kernel.org
In-Reply-To: <50ACEA95.9020909@ira.uka.de>
[-- Attachment #1: Type: Text/Plain, Size: 1442 bytes --]
On Wed 21 Nov 2012 11:52:05 Holger Hellmuth (IKS) escribió:
> Am 21.11.2012 01:13, schrieb Lisandro Damián Nicanor Pérez Meyer:
> > Well, two ideas come to my mind:
> >
> > - detect when using git flow (.git/config contains [gitflow
> > "some_branch"] entries).
>
> Shouldn't it be part of the gitflow package then?
>
> > - Show "swim-lane"-like graphs, including branches that may not be
> > present, but where there (release branches often are created and merged
> > back, for example)
>
> As a general feature there could be a config option gitk reads with an
> ordered list of branch names (with wildcards). Those branches would
> always be printed in gitk as the leftmost branches (i.e. have their own
> lane on the left side). All other branches would be shown normally.
>
> This would give you part of what you want, a special lane at least for
> master and develop and for branches you can group under wildcard branch
> names (for example if you prefix all release branches with "rel-").
>
> And it would give others the ability to make special branches in gitk
> more visible.
>
> (Yes I know, I'm talking again of stuff I won't have time or ability to
> implement ;-). Sigh)
That seems an interesting idea, indeed. Thanks!
--
Either he's dead or my watch has stopped.
-- Groucho Marx
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Marc Branchaud @ 2012-11-21 14:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org>
On 12-11-20 07:05 PM, Junio C Hamano wrote:
> Here is a list of stalled topics I am having trouble deciding what
> to do (the default is to dismiss them around feature freeze).
>
[ snip ]
>
> * mb/remote-default-nn-origin (2012-07-11) 6 commits
> - Teach get_default_remote to respect remote.default.
> - Test that plain "git fetch" uses remote.default when on a detached HEAD.
> - Teach clone to set remote.default.
> - Teach "git remote" about remote.default.
> - Teach remote.c about the remote.default configuration setting.
> - Rename remote.c's default_remote_name static variables.
>
> When the user does not specify what remote to interact with, we
> often attempt to use 'origin'. This can now be customized via a
> configuration variable.
>
> Expecting a re-roll.
>
> "The first remote becomes the default" bit is better done as a
> separate step.
This is still on my list of things to do soon. Unfortunately "soon" seems to
be rather perpetual these days.
If you're tired of carrying the branch feel free to dismiss it and I'll
resurrect the topic when "soon" finally comes around.
M.
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Holger Hellmuth (IKS) @ 2012-11-21 14:52 UTC (permalink / raw)
To: Lisandro Damián Nicanor Pérez Meyer
Cc: Andrew Ardill, git@vger.kernel.org
In-Reply-To: <201211202113.44459.perezmeyer@gmail.com>
Am 21.11.2012 01:13, schrieb Lisandro Damián Nicanor Pérez Meyer:
> Well, two ideas come to my mind:
>
> - detect when using git flow (.git/config contains [gitflow "some_branch"]
> entries).
Shouldn't it be part of the gitflow package then?
> - Show "swim-lane"-like graphs, including branches that may not be present,
> but where there (release branches often are created and merged back, for
> example)
As a general feature there could be a config option gitk reads with an
ordered list of branch names (with wildcards). Those branches would
always be printed in gitk as the leftmost branches (i.e. have their own
lane on the left side). All other branches would be shown normally.
This would give you part of what you want, a special lane at least for
master and develop and for branches you can group under wildcard branch
names (for example if you prefix all release branches with "rel-").
And it would give others the ability to make special branches in gitk
more visible.
(Yes I know, I'm talking again of stuff I won't have time or ability to
implement ;-). Sigh)
^ permalink raw reply
* Re: [PATCH v5 00/15] fast-export and remote-testgit improvements
From: Felipe Contreras @ 2012-11-21 9:46 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips, Felipe Contreras
In-Reply-To: <1352642392-28387-1-git-send-email-felipe.contreras@gmail.com>
On Sun, Nov 11, 2012 at 2:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
Since these are having some problems getting in, let me point out
which I think are important, and which not.
> Felipe Contreras (15):
> fast-export: avoid importing blob marks
This fixes a bug, but it's probably not hitting many people.
> remote-testgit: fix direction of marks
> remote-helpers: fix failure message
I don't care.
> Rename git-remote-testgit to git-remote-testpy
> Add new simplified git-remote-testgit
These I think are good.
> remote-testgit: get rid of non-local functionality
> remote-testgit: remove irrelevant test
> remote-testgit: cleanup tests
Just cleanups.
> remote-testgit: exercise more features
I think it's good to catch more issues, but I don't care much.
> remote-testgit: report success after an import
> remote-testgit: make clear the 'done' feature
These are good, but I could drop them.
> fast-export: trivial cleanup
> fast-export: fix comparison in tests
Obvious and correct, but I don't care.
> fast-export: make sure updated refs get updated
This is the important one. It fixes real issues quite visible on remote helpers.
> fast-export: don't handle uninteresting refs
This is nice, but can be dropped.
I don't see what are the chances of any of them getting merged, but at
least 'fast-export: make sure updated refs get updated' should
definitely go in. Please advice at which level I should drop the
patches, because at this point it doesn't look like any of them are
going in.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Krzysztof Mazur @ 2012-11-21 9:27 UTC (permalink / raw)
To: Paul Fox; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20121121024647.BBCC82E9301@grass.foxharp.boston.ma.us>
On Tue, Nov 20, 2012 at 09:46:47PM -0500, Paul Fox wrote:
> junio c hamano wrote:
> > Here is a list of stalled topics I am having trouble deciding what
> > to do (the default is to dismiss them around feature freeze).
> ...
> > * pf/editor-ignore-sigint (2012-11-11) 5 commits
> >
> > Avoid confusing cases where the user hits Ctrl-C while in the editor
> > session, not realizing git will receive the signal. Since most editors
> > will take over the terminal and will block SIGINT, this is not likely
> > to confuse anyone.
> >
> > Some people raised issues with emacsclient, which are addressed by this
> > re-roll. It should probably also handle SIGQUIT, and there were a
> > handful of other review comments.
> >
> > Anybody interested in moving this forward?
>
> i started this, but then jeff took it and ran with it and made it
> right. i think the remaining changes are small -- if jeff would
> prefer, i can probably finish it. (but i won't guarantee not to
> mess up the "From:" lines. :-)
>
I'm also interested. I sometimes use ":r !command" in vim, so far I never
needed to use Ctrl-C, but maybe in future.
The SIGINT part seems to be finished, we need to decide what about SIGQUIT.
Krzysiek
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-21 8:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vfw43pmp7.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 6:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Never mind that others have said that that's not the current interface
>> (I don't yet see why it would be a good interface after a transition,
>> but maybe it would be). Still, hopefully that clarifies the intended
>> meaning.
>
> Care to explain how the current interface is supposed to work, how
> fast-export and transport-helper should interact with remote helpers
> that adhere to the current interface, and how well/correctly the
> current implementation of these pieces work?
>
> What I am trying to get at is to see where the problem lies. Felipe
> sees bugs in the aggregated whole. Is the root cause of the problems
> he sees some breakages in the current interface? Is the interface
> designed right but the problem is that the implementation of the
> transport-helper is buggy and driving fast-export incorrectly? Or is
> the implementation of the fast-export buggy and emitting wrong results,
> even though the transport-helper is driving fast-export correctly?
> Something else?
Let me give it a shot at explaining the case for remote helpers that
use export/import.
== listing ==
All operations begin with the transport helper requesting a list of
refs. Basically 'git show-ref'.
== fetching ==
In fetch mode the transport helper will initiate the process by
requesting refs to the remote helper, like 'master', or 'devel', and
so on. These refs were previously provided by the remote helper itself
in the "listing" step.
It is the total responsibility of the remote helper to decide what to
do: nothing, only update the ref pointers, retrieve the whole
repository, retrieve only the listed refs, etc. It's also the
responsibility of the remote helper to keep track of marks, last known
commits the refs pointed to, update local transitory repositories,
etc.
It's also the responsibility of the remote helper to throw the right
'feature' commands to fast-import for everything, including where to
store the marks.
Note that there are two sets of marks; the marks of the remote helper,
which could be anything: JSON, text files, binary, etc. and don't
contain git SHA-1's, and the git marks, which do contain git SHA-1's
and are exported/imported by fast-import, but *both* are totally under
control of the remote helper.
At this point, git (transport helper), has absolutely no idea what's
going on, the communication is completely between the remote helper
and fast-import. After this process has finished, control goes back to
the transport helper, which proceeds to check what fast-import did.
Then, the result is shown to the user as the typical fetch that
updated certain refs.
== pushing ==
In this mode the roles are reversed, now git (transport helper) is in
control, and everything that happens depends on what commands are
passed to fast-export. Now the remote helper is a passive receiver of
data, and has two options, receive it or die.
Which refs get updated and how, is the total responsibility of transport helper.
The only control the remote helper has, is before the export begins,
in the configuration (capabilities command) that happens at the very
beginning (before listing), and where it specifies features to
support, which are then used to pass the relevant arguments to
fast-export.
And these capabilities are very limited:
* import-marks
* export-marks
* refspec
After the push has finished, the remote helper then proceeds to report
which refs were actually updated, and the user gets notified.
== details ==
As it should be obvious by now, there's not many ways in which a
remote helper can screw things up (other than the parsing and
generation of data for fast-import/export). The only tricky part is
the refspec.
To function properly, a remote helper should specify a refspec such as
'refs/heads/*:refs/test/heads/*', this way, all the changes a remote
helper does are isolated in a specific refspec namespace, and the
update to normal git happens in a controlled way.
However, the refspec only makes sense in the *fetching* mode; the
remote-helper is supposed to throw updates in the form of 'commit
refs/test/heads/master', not 'commit refs/heads/master' (although in
some case that might work, but I'm not sure which).
But when pushing the remote helper will receive the refs in the normal
form 'refs/heads/master'. Also, the namespaced refs are only updated
when fetching, not when pushing.
Marks are very straightforward; the same import and export marks
should be specified for both importing and exporting.
Everything works mostly fine as long as the remote helper follows
this. Things break in all sorts of ways when it doesn't.
But I want to emphasize again that there's not many ways in which a
remote helper can screw things: marks, or refspec, that's it.
*Specially* when pushing.
== no marks ==
Let's imagine a very simple repository with 3 commits, which gets
pushed to a remote one:
4e891f6 :3
d9d17c3 :2
e1aef7b :1
I'm obviously simplifying the marks, but essentially that's what
fast-export would do when pushing commits to a remote helper; it the
parent of :2 is :1, and the parent of :3 is :2, but the remote side
*never* sees any git SHA-1, because they are not interesting in any
way, there's nothing useful that can be done with them.
The remote side would generate commits such as:
:3 103
:2 102
:1 100
Again, for simplification purposes (you can picture them as mercurial revs).
Now the push has finished. The marks are gone (no marks).
What happens when you fetch? You might think that we will get only the
commits after :3, but that's not the case, the transport helper would
use 'refs/test/heads/master' to find out the last commit, but that
doesn't get updated when pushing, only when fetching, so we would
start from the top.
4e891f6 :3
d9d17c3 :2
e1aef7b :1
:3 103
:2 102
:1 100
The same will happen if you push, because push also uses
'refs/test/heads/master'.
But *now* that we are doing a fetch, the 'refs/test/heads/master'
pointer is updated to 4e891f6. But don't think that those marks are
the same as the previous ones: they happen to be the same because they
were generated the same way, but they are completely independent.
What happens when you push now? Now the 'refs/test/heads/master' is
pointing to 4e891f6, and suppose we have two new commits:
88764ee
4607106
4e891f6 :3 <- I'm putting these for reference, but in reality they are gone
d9d17c3 :2
e1aef7b :1
The transport helper would do an export of '^refs/test/heads/master
refs/heads/master', or '^4e891f6 88764ee'. And here comes the
interesting part:
What is the parent of 4607106? It's not :3, because that mark is gone,
and in fact, even if we sent :3; things would break down because the
other side has no idea what :3 means; it's gone, caput. What really
happens is:
88764ee :2
4607106 :1
This is a new tree. That's exactly what you would expect if you do
'git fast-export ^v1.8.0^ master'; export all the commits as if v1.8.0
was the root.
But in the context of remote helpers, that's not what we want.
What can we do to fix this? Let's suppose that through some magic we
get the parent of 4607106 to be 4e891f6; is that helpful? No. To the
remote helper 4e891f6 is useless. What we need is 103, but without
marks, we can't find that out.
Maybe if we stored it in the last run? We need to parse the git marks,
and then match our marks with those, and we could get a mapping like
'4e891f6 -> 103', but what if the parent is 102? So, we need a mapping
for all the marks, and then we have to store such mapping anyway. And
guess what? We are back to using marks again! Except that instead of
using the standard git way, we are using a custom hacky way.
Are there other solutions? Maybe we can store the information in refs:
4e891f6 refs/test/ids/103
d9d17c3 refs/test/ids/102
e1aef7b refs/test/ids/100
But that also would require parsing the git marks, and going outside
of the intended fast-export tool would kind of defeat the purpose of
being fast an efficient, and still very hacky.
And lets not even go as to what would be needed for 'git fast-export'
to actually generate 4e891f6 in the first place, as that would
probably require changes that would break other things.
So no, you can't do it without marks.
And why are we even discussing about this? Why would anybody want to
avoid marks? Not only there's no other ways to achieve the same, marks
are cheap and efficient, as efficient as any other solution could be,
and then some. And do we have any real remote helpers that try to do
export/import without marks? No, heck, we don't even have fake ones.
It just doesn't work. Seriously.
And my patches actually make it work: if there are no marks, then
_everything_ is pushed. I don't see the point of supporting the
functionality of no marks, clearly nobody is using that because it
just doesn't work. Nobody has shown a shred of evidence to the
contrary. With my patches, at least we try to do something without
failing too miserably.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-21 7:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, git, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vfw43pmp7.fsf@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 6:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I see Felipe keeps repeating that there are bugs, and keeps posting
> patches to change fast-export, but I haven't seen a concrete "No,
> the reason why you see these problems is because you are not using
> the interface correctly; the currrent interface is fine. Here is
> how you can fix your program" from "others".
>
> With such a one-sided discussion, I've been having a hard time
> convincing myself if Felipe's effort is making the interface better,
> or just breaking it even more for existing remote helpers, only to
> fit his world model better.
IIRC you mentioned something about this mailing list being focused on
*technical* merit. I've explained as much as I could, but at the end
of the talk, talk is cheap, the code speaks for itself. I added a new
very very very simple testgit remote helper, so anybody can see what's
going on, and figure out how the interface could be used wrong.
Anybody can modify the bash version of git-remote-testgit and say 'no,
the interface is not broken, here is how you push and pull without
marks'. How hard is it to hack 82 lines of bash code?
But lets assume my testgit is fatally broken, would you, Junio, accept
these patches if I show the same broken behavior with the python
git-remote-testgit?
I'm afraid I have to point out the hard truth; the reason why nobody
is doing that is because a) the interface is truly broken b) if they
try, they most likely would fail, and that would prove they were wrong
in previous discussion, or c) not enough familiarity with the code. I
don't want to point fingers, nor do I intend to offend anybody, but I
cannot find any other explanation of why this patch series, which is
obviously correct (to me), doesn't receive any feedback, even though
in theory, it should be very very very easy to show what's wrong with
the series.
The tests are there, and the remote helper is as simple as it gets.
There's nothing else but fast-export and transport-helper to blame for
the issues. It's that simple.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Johannes Sixt @ 2012-11-21 7:01 UTC (permalink / raw)
To: Lisandro Damián Nicanor Pérez Meyer
Cc: Andrew Ardill, git@vger.kernel.org
In-Reply-To: <201211202113.44459.perezmeyer@gmail.com>
Am 11/21/2012 1:13, schrieb Lisandro Damián Nicanor Pérez Meyer:
> I think the best mock-up would be:
>
> <http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png>
>
> Yes, I'm referring to "swim-lanes" like view. Which may be already there and
> I'm miserably failing to see :-/
Maybe you are just looking for gitk --date-order --branches?
-- Hannes
^ permalink raw reply
* [PATCH 14/13] test-wildmatch: avoid Windows path mangling
From: Johannes Sixt @ 2012-11-21 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vd2z8rq4y.fsf@alter.siamese.dyndns.org>
From: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The MSYS bash mangles arguments that begin with a forward slash
when they are passed to test-wildmatch. This causes tests to fail.
Avoid mangling by prepending "XXX", which is removed by
test-wildmatch before further processing.
[J6t: reworded commit message]
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 11/20/2012 21:11, schrieb Junio C Hamano:
> Thanks, but you need to fix your format-patch somehow.
No, it was Thunderbird. It ate the blank lines when I said "Edit as new"
to forward the patch directly from the mailbox.
Sorry for the inconvenience.
t/t3070-wildmatch.sh | 10 +++++-----
test-wildmatch.c | 8 ++++++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index e6ad6f4..3155eab 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -74,7 +74,7 @@ match 0 0 'foo/bar' 'foo[/]bar'
match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
match 1 0 'foo' '**/foo'
-match 1 x '/foo' '**/foo'
+match 1 x 'XXX/foo' '**/foo'
match 1 0 'bar/baz/foo' '**/foo'
match 0 0 'bar/baz/foo' '*/foo'
match 0 0 'foo/bar/baz' '**/bar*'
@@ -95,8 +95,8 @@ match 0 0 ']' '[!]-]'
match 1 x 'a' '[!]-]'
match 0 0 '' '\'
match 0 x '\' '\'
-match 0 x '/\' '*/\'
-match 1 x '/\' '*/\\'
+match 0 x 'XXX/\' '*/\'
+match 1 x 'XXX/\' '*/\\'
match 1 1 'foo' 'foo'
match 1 1 '@foo' '@foo'
match 0 0 'foo' '@foo'
@@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 74c0864..e384c8e 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -3,6 +3,14 @@
int main(int argc, char **argv)
{
+ int i;
+ for (i = 2; i < argc; i++) {
+ if (argv[i][0] == '/')
+ die("Forward slash is not allowed at the beginning of the\n"
+ "pattern because Windows does not like it. Use `XXX/' instead.");
+ else if (!strncmp(argv[i], "XXX/", 4))
+ argv[i] += 3;
+ }
if (!strcmp(argv[1], "wildmatch"))
return !!wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], "iwildmatch"))
--
1.8.0.1417.gf6038d8
^ permalink raw reply related
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-11-21 5:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, git, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <20121121041735.GE4634@elie.Belkin>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Never mind that others have said that that's not the current interface
> (I don't yet see why it would be a good interface after a transition,
> but maybe it would be). Still, hopefully that clarifies the intended
> meaning.
Care to explain how the current interface is supposed to work, how
fast-export and transport-helper should interact with remote helpers
that adhere to the current interface, and how well/correctly the
current implementation of these pieces work?
What I am trying to get at is to see where the problem lies. Felipe
sees bugs in the aggregated whole. Is the root cause of the problems
he sees some breakages in the current interface? Is the interface
designed right but the problem is that the implementation of the
transport-helper is buggy and driving fast-export incorrectly? Or is
the implementation of the fast-export buggy and emitting wrong results,
even though the transport-helper is driving fast-export correctly?
Something else?
I see Felipe keeps repeating that there are bugs, and keeps posting
patches to change fast-export, but I haven't seen a concrete "No,
the reason why you see these problems is because you are not using
the interface correctly; the currrent interface is fine. Here is
how you can fix your program" from "others".
With such a one-sided discussion, I've been having a hard time
convincing myself if Felipe's effort is making the interface better,
or just breaking it even more for existing remote helpers, only to
fit his world model better.
Help?
^ permalink raw reply
* RE: [BUG] git clean does not remove certain directories
From: Soren Brinkmann @ 2012-11-21 5:02 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <933d806a-abce-4baf-8c3b-9b6742cb8ac7@VA3EHSMHS004.ehs.local>
> Hi,
>
> this use case may be a little awkward but this is the behavior I see:
>
> I have a repository which has a couple of untracked directories which can also
> include git repositories. No submodules, though.
> I used 'git clean -xdf' on the top level of this repo to remove everything
> untracked in it - including the git repositories in sub-directories.
>
> Since using git 1.8.0 the clean operation seems to be 'broken', as output
> indicates all those questionable sub directories are removed - just as in prior
> git versions - but in fact they remain untouched and are _not_ removed.
>
> I attached a shell script creating a hierarchy to reproduce the issue.
> Executing the script creates the git repo 'repo.git' with a couple of tracked
> and untracked dirs/files and two more git repositories within the first one.
>
> If you cd into repo.git and execute 'git clean -xdf' I see the following output:
> Removing repo2.git/
> Removing untracked_dir/
>
> But the directories remain intact when using git 1.8.0.
> With git 1.6.3.2 it works as I expected and removes the
> directories. I'm pretty
> sure the 1.7.x versions did the same, but it's no longer
> installed here.
As additional data point: With git 1.7.9.5 the 'untracked_dir' is deleted, while
'repo2.git' is kept. Output is the same as always, indicating both were deleted.
So, three different git versions gain three different results...
Soren
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-21 4:22 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, git, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <20121121041735.GE4634@elie.Belkin>
On Wed, Nov 21, 2012 at 5:17 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> Of course, transport-helper shouldn't even be specifying the negative
>>> (^) refs, but that's another story.
>>
>> Hrm, I am not sure I understand what you mean by this.
>>
>> How should it be telling the fast-export up to what commit the
>> receiving end should already have the history for (hence they do not
>> need to be sent)? Or are you advocating to re-send the entire
>> history down to the root commit every time?
>
> I think Felipe has mentioned before that he considers it the remote
> helper's responsibility to keep track of what commits have already
> been imported, for example using a marks file.
It's not the remote helper, fast-export does that.
> Never mind that others have said that that's not the current interface
> (I don't yet see why it would be a good interface after a transition,
> but maybe it would be). Still, hopefully that clarifies the intended
> meaning.
The current interface is broken.
not ok 16 - pulling without marks # TODO known breakage
not ok 17 - pushing without marks # TODO known breakage
See? A remote helper without marks doesn't work.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Jonathan Nieder @ 2012-11-21 4:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, git, Johannes Schindelin, Max Horn, Jeff King,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vd2z7rj3y.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> Of course, transport-helper shouldn't even be specifying the negative
>> (^) refs, but that's another story.
>
> Hrm, I am not sure I understand what you mean by this.
>
> How should it be telling the fast-export up to what commit the
> receiving end should already have the history for (hence they do not
> need to be sent)? Or are you advocating to re-send the entire
> history down to the root commit every time?
I think Felipe has mentioned before that he considers it the remote
helper's responsibility to keep track of what commits have already
been imported, for example using a marks file.
Never mind that others have said that that's not the current interface
(I don't yet see why it would be a good interface after a transition,
but maybe it would be). Still, hopefully that clarifies the intended
meaning.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Felipe Contreras @ 2012-11-21 3:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org>
On Wed, Nov 21, 2012 at 1:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Here is a list of stalled topics I am having trouble deciding what
> to do (the default is to dismiss them around feature freeze).
>
> * fc/fast-export-fixes (2012-11-08) 14 commits
>
> Renaming of remote-testgit feels to be a mistake. It probably
> should keep its source in remote-testgit.bash and generate it,
Why generate it? There's nothing to generate. python's source code
needs regeneration, bash's code doesn't.
> and
> moreover, if it wants to rename remote-testgit.py to remote-testpy,
> the new one should be called remote-testbash.
No, remote-testbash is not testing anything that is specific to bash,
it's testing the remote helper framework itself. It could be written
in Ruby, or Python, or C, or anything.
remote-testgit.py is *not* testing the remote helper framework, it's
testing the Python-specific remote helper framework.
IOW. remote-testgit tests this:
transport-helper.c
remote-testpy tests this:
git_remote_helpers/Makefile
git_remote_helpers/__init__.py
git_remote_helpers/git/__init__.py
git_remote_helpers/git/exporter.py
git_remote_helpers/git/git.py
git_remote_helpers/git/importer.py
git_remote_helpers/git/non_local.py
git_remote_helpers/git/repo.py
git_remote_helpers/setup.cfg
git_remote_helpers/setup.py
git_remote_helpers/util.py
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-21 3:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Max Horn, Jeff King, Sverre Rabbelier,
Brandon Casey, Brandon Casey, Jonathan Nieder, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vd2z7rj3y.fsf@alter.siamese.dyndns.org>
On Tue, Nov 20, 2012 at 11:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> Of course, transport-helper shouldn't even be specifying the negative
>> (^) refs, but that's another story.
>
> Hrm, I am not sure I understand what you mean by this.
>
> How should it be telling the fast-export up to what commit the
> receiving end should already have the history for (hence they do not
> need to be sent)? Or are you advocating to re-send the entire
> history down to the root commit every time?
No, it would not re-send the whole history, that's what marks are for.
And right now it doesn't exactly which was the last commit. Let's
suppose the remote helper has a refspec like this:
refs/heads/*:refs/hg/origin/heads/*
1) What happens the first time you push?
5203a268546295ebd895fd87522217ef53bd3313 refs/heads/master
5203a268546295ebd895fd87522217ef53bd3313 refs/remotes/tmp/master
Notice how the remote ref is updated correctly, but it's not the
remote helper refspec, so the next time you push, you will from root.
It's only when you fetch that you get the refspec'ed refs:
5203a268546295ebd895fd87522217ef53bd3313 refs/heads/master
5203a268546295ebd895fd87522217ef53bd3313 refs/hg/tmp/heads/master
5203a268546295ebd895fd87522217ef53bd3313 refs/remotes/tmp/master
So, there's already a mismatch.
2) What happens when you have no marks?
You get something like:
reset refs/heads/heads
from :0
Which is totally useless. Somebody proposed a patch that would replace
the :0 with a git sha-1, but that is equally useless for a remote
helper: we need a hg ref id, or a bzr id, or whatever, and no, there's
mapping between git sha-1's and hg ref ids, there's only git->mark
mark->hg, without marks, there's no way to map the git id to the hg
id.
3) What happens when you have a refspec like this?
*:*
Now nothing works, because we would be requesting ^refs/heads/master
refs/heads/master.
And according to the documentation, this is the default when no
refspec is used, which is not true.
4) What happens when there's no refspec at all.
Now it's even worst; nothing gets done at all:
if (!data->refspecs)
continue;
I documented all this breakages in this patch:
http://article.gmane.org/gmane.comp.version-control.git/209365
not ok 10 - push new branch with old:new refspec # TODO known breakage
ok 11 - cloning without refspec
ok 12 - pulling without refspecs
not ok 13 - pushing without refspecs # TODO known breakage
not ok 14 - pulling with straight refspec # TODO known breakage
not ok 15 - pushing with straight refspec # TODO known breakage
not ok 16 - pulling without marks # TODO known breakage
not ok 17 - pushing without marks # TODO known breakage
And if you apply this patch:
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -750,6 +750,7 @@ static int push_refs_with_export(struct transport
*transport,
struct helper_data *data = transport->data;
struct string_list revlist_args = STRING_LIST_INIT_NODUP;
struct strbuf buf = STRBUF_INIT;
+ struct remote *remote = transport->remote;
helper = get_helper(transport);
@@ -761,22 +762,23 @@ static int push_refs_with_export(struct
transport *transport,
char *private;
unsigned char sha1[20];
- if (!data->refspecs)
+ if (ref->deletion)
+ die("remote-helpers do not support ref deletion");
+
+ if (!ref->peer_ref)
+ continue;
+
+ string_list_append(&revlist_args, ref->peer_ref->name);
+
+ if (!data->import_marks)
continue;
- private = apply_refspecs(data->refspecs,
data->refspec_nr, ref->name);
+
+ private = apply_refspecs(remote->fetch,
remote->fetch_refspec_nr, ref->name);
if (private && !get_sha1(private, sha1)) {
strbuf_addf(&buf, "^%s", private);
string_list_append(&revlist_args,
strbuf_detach(&buf, NULL));
}
free(private);
-
- if (ref->deletion) {
- die("remote-helpers do not support ref deletion");
- }
-
- if (ref->peer_ref)
- string_list_append(&revlist_args, ref->peer_ref->name);
-
}
if (get_exporter(transport, &exporter, &revlist_args))
ok 13 - pushing without refspecs # TODO known breakage
ok 14 - pulling with straight refspec # TODO known breakage
ok 15 - pushing with straight refspec # TODO known breakage
ok 16 - pulling without marks # TODO known breakage
ok 17 - pushing without marks # TODO known breakage
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Topics currently in the Stalled category
From: Paul Fox @ 2012-11-21 2:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-reply-to: <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org> (sfid-20121120_190548_379327_D3EE7D14)
References: <7vpq39up0m.fsf@alter.siamese.dyndns.org> <7vy5hvq1ey.fsf@alter.siamese.dyndns.org> <7vobirq0q2.fsf_-_@alter.siamese.dyndns.org> (sfid-20121120_190548_379327_D3EE7D14)
Fcc: outbox
--------
junio c hamano wrote:
> Here is a list of stalled topics I am having trouble deciding what
> to do (the default is to dismiss them around feature freeze).
...
> * pf/editor-ignore-sigint (2012-11-11) 5 commits
>
> Avoid confusing cases where the user hits Ctrl-C while in the editor
> session, not realizing git will receive the signal. Since most editors
> will take over the terminal and will block SIGINT, this is not likely
> to confuse anyone.
>
> Some people raised issues with emacsclient, which are addressed by this
> re-roll. It should probably also handle SIGQUIT, and there were a
> handful of other review comments.
>
> Anybody interested in moving this forward?
i started this, but then jeff took it and ran with it and made it
right. i think the remaining changes are small -- if jeff would
prefer, i can probably finish it. (but i won't guarantee not to
mess up the "From:" lines. :-)
paul
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 36.0 degrees)
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Andrew Ardill @ 2012-11-21 1:54 UTC (permalink / raw)
To: Lisandro Damián Nicanor Pérez Meyer; +Cc: git@vger.kernel.org
In-Reply-To: <201211202113.44459.perezmeyer@gmail.com>
On 21 November 2012 11:13, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com> wrote:
> ...
> Well, two ideas come to my mind:
>
> - detect when using git flow (.git/config contains [gitflow "some_branch"]
> entries).
I guess this part is just so the next part can be done automatically?
> - Show "swim-lane"-like graphs, including branches that may not be present,
> but where there (release branches often are created and merged back, for
> example)
I think this could be useful in general, however it might struggle
with already merged branches. I may be mistaken here, however I think
in general there is no way to specify which commits belonged to a
certain branch after they have been merged, as branch information is
not kept in the commit object. There may be some exceptions that make
it feasible at times, but a general solution would be to show any
merged branches as part of the same swim-lane, as per current
behaviour, but to have separate branch heads in different swim-lanes.
This would be a nice feature, and is similar to the behaviour in, for
example, Atlassian's Fisheye repository viewer and the GitHub network
view.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Lisandro Damián Nicanor Pérez Meyer @ 2012-11-21 0:13 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451nrcEo3Uxm0x6b39Hq1k-J4=OZPi-Cao7osaiS-w_Z1+Q@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 1974 bytes --]
On Tue 20 Nov 2012 20:56:26 Andrew Ardill escribió:
> On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer
>
> <perezmeyer@gmail.com> wrote:
> > Hi! I am not suscribed to the list, so please CC-me.
>
> That is the default etiquette on this list :)
Great :-)
> > I think this may have been proposed before, but I could not find anything
> > in the web, so I better try myself :)
> >
> > The idea would be to gitk to show a "git flow-like"[0] view when it
> > detects git flow (or the user ask for it or...)
>
> What does it mean to 'show a "git flow-like" view'? Show multiple
> branches? Place commits on each branch in 'swim-lanes', rather than
> moving them around on the horizontal to fit the space available? Some
> more detail, or even a mock-up would help a lot here.
I think the best mock-up would be:
<http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png>
Yes, I'm referring to "swim-lanes" like view. Which may be already there and
I'm miserably failing to see :-/
> > Basiccaly, you can show the main two branches: master and develop. Of
> > course, having the possibility to show feature/release/hotfixes branches
> > would be ideal.
>
> It is already possible to show multiple branches in gitk at the same
> time. You probably have some more specific needs beyond simply showing
> the different branches. Maybe you can be more specific?
Well, two ideas come to my mind:
- detect when using git flow (.git/config contains [gitflow "some_branch"]
entries).
- Show "swim-lane"-like graphs, including branches that may not be present,
but where there (release branches often are created and merged back, for
example)
Maybe some of this is already there and/or it's too much trouble to do so, in
those cases, please accept my apologies :-)
Kinds regards, Lisandro.
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [BUG] git clean does not remove certain directories
From: Soren Brinkmann @ 2012-11-21 0:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]
Hi,
this use case may be a little awkward but this is the behavior I see:
I have a repository which has a couple of untracked directories which can also
include git repositories. No submodules, though.
I used 'git clean -xdf' on the top level of this repo to remove everything
untracked in it - including the git repositories in sub-directories.
Since using git 1.8.0 the clean operation seems to be 'broken', as output
indicates all those questionable sub directories are removed - just as in prior
git versions - but in fact they remain untouched and are _not_ removed.
I attached a shell script creating a hierarchy to reproduce the issue.
Executing the script creates the git repo 'repo.git' with a couple of tracked
and untracked dirs/files and two more git repositories within the first one.
If you cd into repo.git and execute 'git clean -xdf' I see the following output:
Removing repo2.git/
Removing untracked_dir/
But the directories remain intact when using git 1.8.0.
With git 1.6.3.2 it works as I expected and removes the directories. I'm pretty
sure the 1.7.x versions did the same, but it's no longer installed here.
I can see that this behavior may partially be intended, but the tool output
should match its actions. So, either the directories should be removed, or the
output should state, that they are not removed for what reason whatsoever, IMHO
Thanks,
Soren
[-- Attachment #2: reproduce.sh --]
[-- Type: text/plain, Size: 547 bytes --]
#!/bin/sh
mkdir repo.git
cd repo.git
git init
echo foo > tracked_file1
git add tracked_file1
mkdir tracked_dir
echo foo > tracked_dir/tracked_file2
git add tracked_dir/tracked_file2
git commit -m "Adding tracked files"
mkdir repo2.git
echo foo > repo2.git/tracked_file3
mkdir -p untracked_dir/repo3.git
echo foo > untracked_dir/repo3.git/tracked_file4
cd repo2.git
git init
git add tracked_file3
git commit -m "Adding file to subrepo1"
cd ../untracked_dir/repo3.git
git init
git add tracked_file4
git commit -m "Adding file to subrepo2"
cd ../..
^ permalink raw reply
* Topics currently in the Stalled category
From: Junio C Hamano @ 2012-11-21 0:05 UTC (permalink / raw)
To: git
In-Reply-To: <7vy5hvq1ey.fsf@alter.siamese.dyndns.org>
Here is a list of stalled topics I am having trouble deciding what
to do (the default is to dismiss them around feature freeze).
* fc/fast-export-fixes (2012-11-08) 14 commits
Renaming of remote-testgit feels to be a mistake. It probably
should keep its source in remote-testgit.bash and generate it, and
moreover, if it wants to rename remote-testgit.py to remote-testpy,
the new one should be called remote-testbash. There was one reroll
after what used to be queued, but nobody seemed to be interested in
reviewing the series.
This mostly happened while I was away, and judging from the
discussion around this topic (and earlier iterations), I do not
feel comfortable merging this series (or v5 reroll) as-is.
Help?
* pf/editor-ignore-sigint (2012-11-11) 5 commits
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Anybody interested in moving this forward?
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
- config: exit on error accessing any config file
- doc: advertise GIT_CONFIG_NOSYSTEM
- config: treat user and xdg config permission problems as errors
- config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT; I think a bit more refactored approach to consistently
address permission errors across config, exclude and attrs may be
desirable.
Should we merge this as-is and build on top? What are the chances
of potential regressions?
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this, but it seems that there weren't any
activity since then during my absense.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Is this still in "Needs review" state? Are people involved in the
remote interface happy with this change?
* jk/send-email-sender-prompt (2012-11-15) 8 commits
- send-email: do not prompt for explicit repo ident
- Git.pm: teach "ident" to query explicitness
- var: provide explicit/implicit ident information
- var: accept multiple variables on the command line
- ident: keep separate "explicit" flags for author and committer
- ident: make user_ident_explicitly_given static
- t7502: factor out autoident prerequisite
- test-lib: allow negation of prerequisites
Avoid annoying sender prompt in git-send-email, but only when it is
safe to do so.
Perhaps keep only the first three patches, and replace the rest
with the one from Felipe that takes a much simpler approach (the
rationale of that patch needs to be cleaned up first, along the
lines Jeff outlined, though). Frozen until that happens.
* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
- Unify appending signoff in format-patch, commit and sequencer
I am not sure if the logic to refrain from adding a sign-off based
on the existing run of sign-offs is done correctly in this change.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
* mh/ceiling (2012-10-29) 8 commits
- string_list_longest_prefix(): remove function
- setup_git_directory_gently_1(): resolve symlinks in ceiling paths
- longest_ancestor_length(): require prefix list entries to be normalized
- longest_ancestor_length(): take a string_list argument for prefixes
- longest_ancestor_length(): use string_list_split()
- Introduce new function real_path_if_valid()
- real_path_internal(): add comment explaining use of cwd
- Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
I think the fear that this would regress the intended use case of
the environment variable turned out to be unfounded during the
discussion.
Should we merge this as-is to 'next', cook for a while to make sure
nobody screams?
Thanks.
^ permalink raw reply
* Re: [wishlist] support git flow-like view
From: Andrew Ardill @ 2012-11-20 23:56 UTC (permalink / raw)
To: Lisandro Damián Nicanor Pérez Meyer; +Cc: git@vger.kernel.org
In-Reply-To: <201211202043.00293.perezmeyer@gmail.com>
On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer
<perezmeyer@gmail.com> wrote:
>
> Hi! I am not suscribed to the list, so please CC-me.
That is the default etiquette on this list :)
> I think this may have been proposed before, but I could not find anything in
> the web, so I better try myself :)
>
> The idea would be to gitk to show a "git flow-like"[0] view when it detects
> git flow (or the user ask for it or...)
What does it mean to 'show a "git flow-like" view'? Show multiple
branches? Place commits on each branch in 'swim-lanes', rather than
moving them around on the horizontal to fit the space available? Some
more detail, or even a mock-up would help a lot here.
> Basiccaly, you can show the main two branches: master and develop. Of course,
> having the possibility to show feature/release/hotfixes branches would be
> ideal.
It is already possible to show multiple branches in gitk at the same
time. You probably have some more specific needs beyond simply showing
the different branches. Maybe you can be more specific?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #06; Mon, 19)
From: Junio C Hamano @ 2012-11-20 23:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vpq39up0m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
> Bunch of topics have been merged to 'next'.
>
> We are at the beginning of the 5th week of this release cycle
> (cf. http://tinyurl.com/gitcal), and I've moved many topics to the
> Stalled category, which will be discarded without prejudice soonish
> unless there are some updates. I am still a bit behind on some
> topics and already posted rerolls may have to be pulled in.
It feels a bit too busy/loud to issue two "What's cooking" in a row,
so here is an informal update.
- The following have graduated to 'master'.
cn/config-missing-path
jk/checkout-out-of-unborn
jk/maint-gitweb-xss
jk/maint-http-half-auth-fetch
jl/submodule-rm
kb/preload-index-more
mg/replace-resolve-delete
mh/alt-odb-string-list-cleanup
ml/cygwin-mingw-headers
pw/maint-p4-rcs-expansion-newline
rh/maint-gitweb-highlight-ext
ta/doc-cleanup
- Many topics have been merged to 'maint' in preparation for 1.8.0.1.
mg/maint-pull-suggest-upstream-to
mm/maint-doc-commit-edit
as/maint-doc-fix-no-post-rewrite
rs/lock-correct-ref-during-delete
rf/maint-mailmap-off-by-one
jk/maint-diff-grep-textconv
js/format-2047
sz/maint-curl-multi-timeout
po/maint-refs-replace-docs
ph/pull-rebase-detached
mm/maint-doc-remote-tracking
rs/branch-del-symref
nd/grep-true-path
jc/grep-pcre-loose-ends (early part)
da/mergetools-p4
jc/test-say-color-avoid-echo-escape
bw/config-lift-variable-name-length-limit
- A few topics have been resurrected from the stalled category to
cooking:
pp/gitweb-config-underscore
jc/apply-trailing-blank-removal
^ 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