Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)

2014-03-19 Thread Max Horn

On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:

 Torsten Bögershausen tbo...@web.de 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)

2014-03-19 Thread Max Horn

On 19.03.2014, at 11:53, Max Horn m...@quendi.de wrote:

 
 On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:
 
 Torsten Bögershausen tbo...@web.de 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)

2014-03-19 Thread Max Horn


 Am 19.03.2014 um 18:04 schrieb Junio C Hamano gits...@pobox.com:
 
 Max Horn m...@quendi.de writes:
 
 On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:
 
 Torsten Bögershausen tbo...@web.de 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)

2014-03-19 Thread Junio C Hamano
Max Horn m...@quendi.de 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)

2014-03-19 Thread Junio C Hamano
Max Horn m...@quendi.de writes:

 On 17.03.2014, at 18:01, Junio C Hamano gits...@pobox.com wrote:

 Torsten Bögershausen tbo...@web.de 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)

2014-03-17 Thread Junio C Hamano
Torsten Bögershausen tbo...@web.de 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)

2014-03-17 Thread Junio C Hamano
Philip Oakley philipoak...@iee.org 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)

2014-03-17 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com 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)

2014-03-17 Thread Junio C Hamano
Duy Nguyen pclo...@gmail.com 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)

2014-03-17 Thread Philip Oakley

From: Ramkumar Ramachandra artag...@gmail.com

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)

2014-03-17 Thread Philip Oakley

From: Junio C Hamano gits...@pobox.com

Philip Oakley philipoak...@iee.org 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 something' 
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)

2014-03-17 Thread Jeff King
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)

2014-03-16 Thread Philip Oakley

From: Junio C Hamano gits...@pobox.com

--
[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)

2014-03-16 Thread 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.

 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)

2014-03-15 Thread Torsten Bögershausen
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


Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)

2014-03-15 Thread Duy Nguyen
On Sat, Mar 15, 2014 at 5:09 AM, Junio C Hamano gits...@pobox.com 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