Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Max Horn writes: > On 17.03.2014, at 18:01, Junio C Hamano wrote: > >> Torsten Bögershausen writes: >> >>> On 2014-03-14 23.09, Junio C Hamano wrote: * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit - remote-hg: do not fail on invalid bookmarks Reported to break tests ($gmane/240005) Expecting a reroll. >>> I wonder what should happen here. >>> The change breaks all the tests in test-hg-hg-git.sh >>> (And the breakage may prevent us from detecting other breakages) >>> >>> The ideal situation would be to have an extra test case for the problem >>> which we try to fix with this patch. >>> >>> Antoine, is there any way to make your problem reproducable ? >>> And based on that, to make a patch which passes all test cases ? >> >> After re-reading the thread briefly (there're just five messages) >> >> http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069 > > For some reason, that link does not contain all messages from that > conversation (unfortunately, I have seen GMane do that on multiple > occasions. I hence try not to rely on it for reviewing email > history -- I just don't trust it). In particular, it misses this > crucial post: [jc: please avoid overlong lines; I re-flowed above] > http://thread.gmane.org/gmane.comp.version-control.git/239830 Interesting. > The (or at least "a") root cause has actually been > discovered. Would a patch that adds an xfail test case for it be > acceptable? Do you mean a patch that only adds a new test that expects a failure to the current code, without touching the current code that has the bug it exposes? That would be a good place to start. > ... As a matter of fact, I a know a few more bugs in remote-hg for > which I could produce xfail test cases. Of course I'd prefer to > put them in together with a fix, but I don't know when I can get > to that, if ever. So, would such changes be welcome? Surely. That is to keep tabs on bugs in an actionable form; it is a better way of bug tracking than having a bug-tracker that is not actively maintained, I would think. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Max Horn writes: > So, one more silly (bikeshedding) question: should I do this as one big > patch adding multiple xfail tests - or one commit per test, with perhaps a > brief description of the issue at hand? Or should a code comment next to > the failing test explain things? Judging from the next paragraph, one patch per issue sounds like a good organization to help those who would want to fix these issues. > Actually, some of those bugs might require a lengthy background > explanation, so yet another variant would be to write an email here > With an explanation, then add a gmane ref to the commit message... Please first try to find a way that does not need any external references---not everybody is always online. A two-page description in the log message for a new five-line test_expect_fail piece is perfectly fine. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
> Am 19.03.2014 um 18:04 schrieb Junio C Hamano : > > Max Horn writes: > >>> On 17.03.2014, at 18:01, Junio C Hamano wrote: >>> >>> Torsten Bögershausen writes: >>> > On 2014-03-14 23.09, Junio C Hamano wrote: > * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit > - remote-hg: do not fail on invalid bookmarks > > Reported to break tests ($gmane/240005) > Expecting a reroll. I wonder what should happen here. The change breaks all the tests in test-hg-hg-git.sh (And the breakage may prevent us from detecting other breakages) The ideal situation would be to have an extra test case for the problem which we try to fix with this patch. Antoine, is there any way to make your problem reproducable ? And based on that, to make a patch which passes all test cases ? >>> >>> After re-reading the thread briefly (there're just five messages) >>> >>> http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069 >> >> For some reason, that link does not contain all messages from that >> conversation (unfortunately, I have seen GMane do that on multiple >> occasions. I hence try not to rely on it for reviewing email >> history -- I just don't trust it). In particular, it misses this >> crucial post: > > [jc: please avoid overlong lines; I re-flowed above] Sorry. If anybody knows a way to tech Mail.app to auto-wrap long lines, I'd appreciate a hint. > >> http://thread.gmane.org/gmane.comp.version-control.git/239830 > > Interesting. > >> The (or at least "a") root cause has actually been >> discovered. Would a patch that adds an xfail test case for it be >> acceptable? > > Do you mean a patch that only adds a new test that expects a failure > to the current code, without touching the current code that has the > bug it exposes? Exactly. > That would be a good place to start. Ok. > >> ... As a matter of fact, I a know a few more bugs in remote-hg for >> which I could produce xfail test cases. Of course I'd prefer to >> put them in together with a fix, but I don't know when I can get >> to that, if ever. So, would such changes be welcome? > > Surely. That is to keep tabs on bugs in an actionable form; it is a > better way of bug tracking than having a bug-tracker that is not > actively maintained, I would think. Yeah, makes sense. So, one more silly (bikeshedding) question: should I do this as one big patch adding multiple xfail tests - or one commit per test, with perhaps a brief description of the issue at hand? Or should a code comment next to the failing test explain things? Actually, some of those bugs might require a lengthy background explanation, so yet another variant would be to write an email here With an explanation, then add a gmane ref to the commit message... > > > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
On 19.03.2014, at 11:53, Max Horn wrote: > > On 17.03.2014, at 18:01, Junio C Hamano wrote: > >> Torsten Bögershausen writes: >> >>> On 2014-03-14 23.09, Junio C Hamano wrote: * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit - remote-hg: do not fail on invalid bookmarks Reported to break tests ($gmane/240005) Expecting a reroll. >>> I wonder what should happen here. >>> The change breaks all the tests in test-hg-hg-git.sh >>> (And the breakage may prevent us from detecting other breakages) >>> >>> The ideal situation would be to have an extra test case for the problem >>> which we try to fix with this patch. > [...] > The (or at least "a") root cause has actually been discovered. Would a patch > that adds an xfail test case for it be acceptable? > > As to the why the proposed patch causes test failures: I think this is due to > the fact that remote-hg inserts a fake "master" branch (resp. "bookmark" in > the hg terminology). Now, in those test cases, a hg repository gets created > that actually contains a "null" bookmark named "master". When the proposed > fix for the problem is added, this bookmarks gets ignored. But at that point, > remote-hg already determined that there is a hg bookmark named "master", and > adjusts how it works accordingly -- when we then remove that bookmarks, > things go awry. > > But I might be wrong here, and in any case, did not yet have time to come up > with a proper fix. Actually, scratch that, I just came up with a fix, and also tests. Will submit shortly. I'd still like to know whether it is OK to submit further patches with (x?)failing test cases? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
On 17.03.2014, at 18:01, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 2014-03-14 23.09, Junio C Hamano wrote:
>>> * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
>>> - remote-hg: do not fail on invalid bookmarks
>>>
>>> Reported to break tests ($gmane/240005)
>>> Expecting a reroll.
>> I wonder what should happen here.
>> The change breaks all the tests in test-hg-hg-git.sh
>> (And the breakage may prevent us from detecting other breakages)
>>
>> The ideal situation would be to have an extra test case for the problem
>> which we try to fix with this patch.
>>
>> Antoine, is there any way to make your problem reproducable ?
>> And based on that, to make a patch which passes all test cases ?
>
> After re-reading the thread briefly (there're just five messages)
>
> http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069
For some reason, that link does not contain all messages from that conversation
(unfortunately, I have seen GMane do that on multiple occasions. I hence try
not to rely on it for reviewing email history -- I just don't trust it). In
particular, it misses this crucial post:
http://thread.gmane.org/gmane.comp.version-control.git/239830
I call it crucial because it describes how to make a reproducible test cases
out of this, in which a legitimate hg repository leads to a remote-hg error
preventing the user from normal operation.
>
> I think the "breakage" the patch tries to fix seems to be of dubious
> nature in the first place ("I don't know how I ended-up with such a
> bookmark", Antoine says in $gmane/239800), and it has been in
> "Expecting a reroll" state in response to "I will try to come-up
> with an improved version" in $gmane/240069 but nothing has happened
> for a few months.
>
> At this point I think it would be OK for me to discard the topic
> (without prejudice); if the root cause of the issue (if there is
> one) and a proper fix is discovered in the future, the topic can
> come back with a fresh patch, but it appears to me that keeping the
> above patch in my tree would not help anybody.
The (or at least "a") root cause has actually been discovered. Would a patch
that adds an xfail test case for it be acceptable?
As to the why the proposed patch causes test failures: I think this is due to
the fact that remote-hg inserts a fake "master" branch (resp. "bookmark" in the
hg terminology). Now, in those test cases, a hg repository gets created that
actually contains a "null" bookmark named "master". When the proposed fix for
the problem is added, this bookmarks gets ignored. But at that point, remote-hg
already determined that there is a hg bookmark named "master", and adjusts how
it works accordingly -- when we then remove that bookmarks, things go awry.
But I might be wrong here, and in any case, did not yet have time to come up
with a proper fix. What I do have is a test case, that I could turn into an
xfail test. As a matter of fact, I a know a few more bugs in remote-hg for
which I could produce xfail test cases. Of course I'd prefer to put them in
together with a fix, but I don't know when I can get to that, if ever. So,
would such changes be welcome?
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
On Sun, Mar 16, 2014 at 06:30:49PM -, Philip Oakley wrote:
> >* jk/branch-at-publish-rebased (2014-01-17) 5 commits
> >- t1507 (rev-parse-upstream): fix typo in test title
> >- implement @{publish} shorthand
> >- branch_get: provide per-branch pushremote pointers
> >- branch_get: return early on error
> >- sha1_name: refactor upstream_mark
> >
> >Give an easier access to the tracking branches from "other" side in
> >a triangular workflow by introducing B@{publish} that works in a
> >similar way to how B@{upstream} does.
> >
> >Meant to be used as a basis for whatever Ram wants to build on.
>
> To me 'publish' didn't fel right, though the later 'push' suggestion felt
> honest.
> (http://git.661346.n2.nabble.com/RFC-PATCH-format-patch-introduce-branch-forkedFrom-tp7601682p7603725.html)
FWIW, I think I like "@{push}" at this point, and we should perhaps add
"@{pull}" as an alias for "@{upstream}" for consistency.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
From: "Junio C Hamano" "Philip Oakley" writes: * po/git-help-user-manual (2014-02-18) 1 commit - Provide a 'git help user-manual' route to the docbook I am not sure if this is even needed. My rhetorical question would be "what should 'git help user-manual' do?" for the beginner, ... Why would any _beginner_ even be expected to ask "git help" everything, including "user-manual", in the first place? Wouldn't things like /usr/share/doc/git-doc/ be the place to help them in a consistent manner across different programs instead? It would be my view that 'git help' would be the first place for a _beginner_ to start. In some ways it depends on what background one expects the beginner to have, and whether they know well their way around their machine, which often isn't the case. Given that Git is available on many systems as a packaged application, the user may not even know where the raw documentation is held. That's certainly likely for those on Windows ;-) ... do we have a sort of policy on ensuring that the majority of user documentation should be available (or at least referenced) via the 'git help' mechanism? I doubt that there should be such a policy. "git help" is primarily to show the manual pages, and some technical details docs that are referenced from manpages may need to be reachable from it. My approach, as you may have gathered, would be that the basic documenation should at least be available via a 'git help ' mechanism, even if advanced users already use alternative means suitable to their expertise. The user manual, on the other hand, may reference individual manpages but because it is primarily a document that shows the overall flow to employ different commands, individual manpages referring to the user manual feels entirely the other way around. Ideally (from my viewpoint) there would be a way to directly access the current "user-manual" via the 'git help'. It's whether special casing the user-manual would be sensible. At the moment 'git help' prompts for 'git help -g' which then lists the leading guides (I have a -gg option to list all guides in draft), so beginners who read the prompts would at least be led to the tutorial, which does have an extra link into the user-manual. Otherwise it's catch-22 - if a user doesn't know it's there they might never find it. One has to lead the horse to the water before it can drink, even though some never do ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
From: "Ramkumar Ramachandra"
Philip Oakley wrote:
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
also its contents are a bit stale. It may be a good first step in
the right direction, but needs more work to at least get the
mark-up right before public consumption.
I'm not sure what elements you feel need adjustment. At the moment
the
markup formats quite reasonably to my eyes, both as an HTML page and
as a
man page.
I sent you a small patch fixing some minor markup issues.
Thanks, I'll look through them. There was one part where there was a
sub-list which made the numbering look wrong, but it formatted fine.
That said, the (lack of) introduction could do with a paragraph to
introduce
the "guide". I have something in draft..
I had a thought that it may be worth a slight rearrangement to add a
section
covering the setting up of one's remotes, depending whether it was
forked,
corporate, or independent, but the lack of resolution on the next
{publish/push} topic makes such a re-write awkward at this stage.
(Ram cc'd)
Before attempting to introduce remote.pushdefault and triangular
workflows, I'd first fix the main issue: stale content.
My priority order was to fix accessibility, then basic format, followed
by a nicer intro, and then the "current" content, rather than get hung
up on initially word-smithing new content, which could go down a rabbit
hole which would leaving the stale content in place. Hopefully the patch
will bring out some more clarifications that folks feel are outdated or
no longer informative.
I'm not sure
who uses git show-branch or mailx anymore, for instance.
I hadn't even realised mailx was refering to specific program rather
than a generic "mail-MUA-X" ;-)
regards
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Duy Nguyen writes: > There are two minor fixes [1] [2] on top of v5, but I'm not going to > send v6 again unless I see more substantial changes. Just give me a > signal or something before you merge to next so I have a chance to fix > them if v6 never comes. > > [1] http://article.gmane.org/gmane.comp.version-control.git/243693 > [2] http://article.gmane.org/gmane.comp.version-control.git/243692 Thanks. I'd first need to give you a signal when I replace what was queued with v5, as I have been way behind on this topic and another large one from Michael, partly due to the "micro" storm for the past few weeks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Ramkumar Ramachandra writes: > ... I'd first fix the main issue: stale content. I'm not sure > who uses git show-branch or mailx anymore, for instance. Unfortunately, I haven't seen a representation better than what show-branch gives me when assessing what needs to happen during rebases of multiple topics some of which depend on other topics. "git log --oneline --graph" is *not* it, with too much clutter. I do not think "stale" is the issue. Common-ness may be an issue, as the usage of Git surely does not have to involve show-branch for a simple workflow, e.g. a beginning standalone developer's. The show-branch (and mailx) example are headed by "My typical Git day" in the "Integrator" section (emphasis on "My"---it was not meant to be "You ought to do like I do because I know this is the best current practice" back when it was written, as none of us had enough experience to declare what the BCP was). You may argue the command set shown there may be specific to "My" usage, and it is atypical for the "Integrator" workflow. We could try to come up with a different/better workflows for each classes of developers to replace that "examples" sections, and that will be the first step to update the listed set of commands for each classes, I would think. You need to realize that the workflow described in the examples section is a real, battle tested one, not something that came out of thin air, though. The way forward would be to think about the following things, in the order listed here: (1) Review the classes of developers. Is the classification we have in the document still good? Do we need to add new classes of developers? Do we need to collapse some into one? (2) For each class of developers, review the workflow illustrated in the "Examples": . Do the steps illustrate a typical flow of activities for the class of developers? Are there steps that typically happens during a developer's day that are missing in the flow? Are some of the steps in the example unnecessary? . Have we made improvements to various Porcelain commands since the document was written? Do we have better ways to achieve some steps illustrated there? (3) For each class of developers, review the commands listed before the "Examples" section and adjust to the "Examples" updated in the second step. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
"Philip Oakley" writes: >> * po/git-help-user-manual (2014-02-18) 1 commit >> - Provide a 'git help user-manual' route to the docbook >> >> I am not sure if this is even needed. > > My rhetorical question would be "what should 'git help user-manual' > do?" for the beginner, ... Why would any _beginner_ even be expected to ask "git help" everything, including "user-manual", in the first place? Wouldn't things like /usr/share/doc/git-doc/ be the place to help them in a consistent manner across different programs instead? > ... do we have a sort of policy on ensuring > that the majority of user documentation should be available (or at > least referenced) via the 'git help' mechanism? I doubt that there should be such a policy. "git help" is primarily to show the manual pages, and some technical details docs that are referenced from manpages may need to be reachable from it. The user manual, on the other hand, may reference individual manpages but because it is primarily a document that shows the overall flow to employ different commands, individual manpages referring to the user manual feels entirely the other way around. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Torsten Bögershausen writes:
> On 2014-03-14 23.09, Junio C Hamano wrote:
>> * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit
>> - remote-hg: do not fail on invalid bookmarks
>>
>> Reported to break tests ($gmane/240005)
>> Expecting a reroll.
> I wonder what should happen here.
> The change breaks all the tests in test-hg-hg-git.sh
> (And the breakage may prevent us from detecting other breakages)
>
> The ideal situation would be to have an extra test case for the problem
> which we try to fix with this patch.
>
> Antoine, is there any way to make your problem reproducable ?
> And based on that, to make a patch which passes all test cases ?
After re-reading the thread briefly (there're just five messages)
http://thread.gmane.org/gmane.comp.version-control.git/239797/focus=240069
I think the "breakage" the patch tries to fix seems to be of dubious
nature in the first place ("I don't know how I ended-up with such a
bookmark", Antoine says in $gmane/239800), and it has been in
"Expecting a reroll" state in response to "I will try to come-up
with an improved version" in $gmane/240069 but nothing has happened
for a few months.
At this point I think it would be OK for me to discard the topic
(without prejudice); if the root cause of the issue (if there is
one) and a proper fix is discovered in the future, the topic can
come back with a fresh patch, but it appears to me that keeping the
above patch in my tree would not help anybody.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
Philip Oakley wrote:
>> * po/everyday-doc (2014-01-27) 1 commit
>> - Make 'git help everyday' work
>>
>> This may make the said command to emit something, but the source is
>> not meant to be formatted into a manual pages to begin with, and
>> also its contents are a bit stale. It may be a good first step in
>> the right direction, but needs more work to at least get the
>> mark-up right before public consumption.
>
> I'm not sure what elements you feel need adjustment. At the moment the
> markup formats quite reasonably to my eyes, both as an HTML page and as a
> man page.
I sent you a small patch fixing some minor markup issues.
> That said, the (lack of) introduction could do with a paragraph to introduce
> the "guide". I have something in draft..
>
> I had a thought that it may be worth a slight rearrangement to add a section
> covering the setting up of one's remotes, depending whether it was forked,
> corporate, or independent, but the lack of resolution on the next
> {publish/push} topic makes such a re-write awkward at this stage. (Ram cc'd)
Before attempting to introduce remote.pushdefault and triangular
workflows, I'd first fix the main issue: stale content. I'm not sure
who uses git show-branch or mailx anymore, for instance.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
From: "Junio C Hamano"
--
[Stalled]
...
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
also its contents are a bit stale. It may be a good first step in
the right direction, but needs more work to at least get the
mark-up right before public consumption.
I'm not sure what elements you feel need adjustment. At the moment the
markup formats quite reasonably to my eyes, both as an HTML page and as
a man page.
That said, the (lack of) introduction could do with a paragraph to
introduce the "guide". I have something in draft..
I had a thought that it may be worth a slight rearrangement to add a
section covering the setting up of one's remotes, depending whether it
was forked, corporate, or independent, but the lack of resolution on the
next {publish/push} topic makes such a re-write awkward at this stage.
(Ram cc'd)
Some guidance would be a help.
Will hold.
* jk/branch-at-publish-rebased (2014-01-17) 5 commits
- t1507 (rev-parse-upstream): fix typo in test title
- implement @{publish} shorthand
- branch_get: provide per-branch pushremote pointers
- branch_get: return early on error
- sha1_name: refactor upstream_mark
Give an easier access to the tracking branches from "other" side in
a triangular workflow by introducing B@{publish} that works in a
similar way to how B@{upstream} does.
Meant to be used as a basis for whatever Ram wants to build on.
To me 'publish' didn't fel right, though the later 'push' suggestion
felt honest.
(http://git.661346.n2.nabble.com/RFC-PATCH-format-patch-introduce-branch-forkedFrom-tp7601682p7603725.html)
Will hold.
--
[Cooking]
* po/git-help-user-manual (2014-02-18) 1 commit
- Provide a 'git help user-manual' route to the docbook
I am not sure if this is even needed.
My rhetorical question would be "what should 'git help user-manual' do?"
for the beginner, and do we have a sort of policy on ensuring that the
majority of user documentation should be available (or at least
referenced) via the 'git help' mechanism?
It feels odd to make the user-manual the one manual that can't be served
via the git man pages.
Will discard.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
On Sat, Mar 15, 2014 at 5:09 AM, Junio C Hamano wrote: > * nd/multiple-work-trees (2014-03-06) 28 commits > - FIXUP: minimum compilation fix > - count-objects: report unused files in $GIT_DIR/repos/... > - gc: support prune --repos > - gc: style change -- no SP before closing bracket > - prune: strategies for linked checkouts > - checkout: detach if the branch is already checked out elsewhere > - checkout: clean up half-prepared directories in --to mode > - checkout: support checking out into a new working directory > - use new wrapper write_file() for simple file writing > - wrapper.c: wrapper to open a file, fprintf then close > - setup.c: support multi-checkout repo setup > - setup.c: detect $GIT_COMMON_DIR check_repository_format_gently() > - setup.c: convert check_repository_format_gently to use strbuf > - setup.c: detect $GIT_COMMON_DIR in is_git_directory() > - setup.c: convert is_git_directory() to use strbuf > - git-stash: avoid hardcoding $GIT_DIR/logs/ > - *.sh: avoid hardcoding $GIT_DIR/hooks/... > - git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects > - Add new environment variable $GIT_COMMON_DIR > - commit: use SEQ_DIR instead of hardcoding "sequencer" > - fast-import: use git_path() for accessing .git dir instead of get_git_dir() > - reflog: avoid constructing .lock path with git_path > - *.sh: respect $GIT_INDEX_FILE > - Make git_path() aware of file relocation in $GIT_DIR > - path.c: group git_path(), git_pathdup() and strbuf_git_path() together > - path.c: rename vsnpath() to do_git_path() > - Convert git_snpath() to strbuf_git_path() > - path.c: make get_pathname() return strbuf instead of static buffer > > The series needs a serious review. There are two minor fixes [1] [2] on top of v5, but I'm not going to send v6 again unless I see more substantial changes. Just give me a signal or something before you merge to next so I have a chance to fix them if v6 never comes. [1] http://article.gmane.org/gmane.comp.version-control.git/243693 [2] http://article.gmane.org/gmane.comp.version-control.git/243692 -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
On 2014-03-14 23.09, Junio C Hamano wrote: > * ap/remote-hg-skip-null-bookmarks (2014-01-02) 1 commit > - remote-hg: do not fail on invalid bookmarks > > Reported to break tests ($gmane/240005) > Expecting a reroll. I wonder what should happen here. The change breaks all the tests in test-hg-hg-git.sh (And the breakage may prevent us from detecting other breakages) The ideal situation would be to have an extra test case for the problem which we try to fix with this patch. Antoine, is there any way to make your problem reproducable ? And based on that, to make a patch which passes all test cases ? Thanks /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
