Re: [PATCH v4 3/3] range-diff: make diff option behavior (e.g. --stat) consistent

2018-11-09 Thread Stephen & Linda Smith 
On Friday, November 9, 2018 3:18:03 AM MST Ævar Arnfjörð Bjarmason wrote:
> 
> But we should behave consistently with "diff" in anticipation of such
> output being useful in the future, because it would make for confusing
> UI if two "diff" and "range-diff" behaved differently when it came to
 's/ two//'

> how they interpret diff options.
>

Re: [PATCH v3 1/2] range-diff doc: add a section about output stability

2018-11-07 Thread Stephen & Linda Smith 
On Wednesday, November 7, 2018 5:22:01 AM MST Ævar Arnfjörð Bjarmason wrote:
> +OUTPUT STABILITY
> +
> +
> +The output of the `range-diff` command is subject to change. It is
> +intended to be human-readable porcelain output, not something that can
> +be used across versions of Git to get a textually stable `range-diff`
> +(as opposed to something like the `--stable` option to
> +linkgit:git-patch-id[1]). There's also no equivalent of
> +linkgit:git-apply[1] for `range-diff`, the output is not intended to
> +be machine-readable.
> +
> +This is particularly true when passing in diff options. Currently some
> +options like `--stat` can as an emergent effect produce output that's

"`--stat` can as an emergent": I read that for times to decided it was correct 
grammar.   Should it be reworded to read better?   Just a nit.

> +quite useless in the context of `range-diff`. Future versions of
> +`range-diff` may learn to interpret such options in a manner specifc
> +to `range-diff` (e.g. for `--stat` summarizing how the diffstat
> +changed).

Re: [PATCH 2/2] mingw: fix getcwd when the parent directory cannot be queried

2018-10-23 Thread Stephen & Linda Smith 
On Tuesday, October 23, 2018 3:52:49 AM MST you wrote:
> From: Anton Serbulov 
> 
> `GetLongPathName()` function may fail when it is unable to query
> the parent directory of a path component to determine the long name
> for that component. It happens, because of it uses `FindFirstFile()`
s/of it/it/

> function for each next short part of path. The `FindFirstFile()`
> requires `List Directory` and `Synchronize` desired access for a calling
> process.

Re: How to handle patch series conflicts

2018-10-07 Thread Stephen & Linda Smith 
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> Stephen & Linda Smith  writes:
> > Junio -
> > 
> > On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
> >> > t7500-commit.sh
> >> > t7501-commit.sh
> >> > t7502-commit.sh
> >> > t7509-commit.sh
> >> 
> >> These seem to have organically grown and it is very likely that ones
> >> later introduced were added more from laziness.

Junio - I've been working this but would like your opinion on 7500, 7501 and 
now 7510. 

I note that the the commit tests have intermixed functionality.  An example is 
signoff tests that are in the three tests I mentioned. 

I've been tempted multiple times over the last week to just merge the tests 
into a single script, but that doesn't seem right either.

So would you prefer a single script?   Would you prefer me to move tests 
around?

sps

Re: What's cooking in git.git (Sep 2018, #02; Tue, 11)

2018-09-12 Thread Stephen & Linda Smith 
On Wednesday, September 12, 2018 12:13:23 AM MST Junio C Hamano wrote:
> Stephen & Linda Smith  writes:
> > On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
> >> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
> >> 
> >>  - WIP: roll wt_status_state into wt_status and populate in the collect
> >> 
> >> phase (this branch uses ss/wt-status-committable.)
> >> 
> >> * ss/wt-status-committable (2018-09-07) 4 commits
> >> 
> >>  - wt-status.c: set the committable flag in the collect phase
> >>  - t7501: add test of "commit --dry-run --short"
> >>  - wt-status: rename commitable to committable
> >>  - wt-status.c: move has_unmerged earlier in the file
> >>  (this branch is used by jc/wt-status-state-cleanup.)
> > 
> > I note that the jc/wt-status-state-cleanup branch is a patch "for
> > illustration purposes only" [1].
> > 
> > I was about to update that patch to start dealing with the free() function
> > calls, but noted you added the patch.  Do you want me to take that patch
> > and continue on?  Or does someone else have something in progress?
> 
> I do not plan to.  
Ok ... from the wording I wasn't sure if there wasn't another developer 
working this.  I will pick up that patch and continue.

> In general, anything that is only in 'pu' is a
> fair game---when a better alternative appears, or a discussion leads
> to a conclusion that a change is unneeded, they are replaced and/or
> discarded.  Just think of them as being kept slightly better record
> of existence than merely being in the list archive, nothing more.

Thanks that confirmed my reading of the Documentation/gitworkflows.txt.

Re: What's cooking in git.git (Sep 2018, #02; Tue, 11)

2018-09-11 Thread Stephen & Linda Smith 
On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
> 
> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
>  - WIP: roll wt_status_state into wt_status and populate in the collect
> phase (this branch uses ss/wt-status-committable.)
> 
> * ss/wt-status-committable (2018-09-07) 4 commits
>  - wt-status.c: set the committable flag in the collect phase
>  - t7501: add test of "commit --dry-run --short"
>  - wt-status: rename commitable to committable
>  - wt-status.c: move has_unmerged earlier in the file
>  (this branch is used by jc/wt-status-state-cleanup.)
> 

I note that the jc/wt-status-state-cleanup branch is a patch "for illustration 
purposes only" [1].

I was about to update that patch to start dealing with the free() function 
calls, but noted you added the patch.  Do you want me to take that patch and 
continue on?  Or does someone else have something in progress?

sps

[1] https://public-inbox.org/git/20180906005329.11277-1-isch...@cox.net/T/
#m3554b678d23fd8d7bc702d83667bebacdf02d8aa

Re: Mailsplit

2018-09-07 Thread Stephen & Linda Smith 
On Friday, September 7, 2018 8:15:43 AM MST Kevin Daudt wrote:
> On Wed, Sep 05, 2018 at 09:17:29PM -0700, Stephen & Linda Smith wrote:
> 
> This is the mailsplit command, and should be executed when running `git
> mailsplit`. What does git --exec-dir return?
> 

The other night when I ran "git mailsplit", I recieved an unknown command 
response.  Since then I have upated to 2.19.0 plush my submitted patches for 
git commit.  With the new build mailsplit is found.

I don't know what was wrong before.

Re: [PATCH v3 0/4] wt-status.c: commitable flag

2018-09-06 Thread Stephen & Linda Smith 
On Thursday, September 6, 2018 12:38:55 AM MST Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 06 2018, Stephen P. Smith wrote:
> Sometimes you send mail from this address as "Stephen & Linda Smith
> ", do we also need Linda Smith's Signed-Off-By? :)

My wife and I share one email account.   If I use the GUI email client to 
respond to emails then her name is on the From line (I could edit future 
emails).

When I am submitting patches/updates, I do so under my name since it is 
"Stephen P. Smith" that is creating the patch.   

I've never had anyone ask before.

Re: Mailsplit

2018-09-06 Thread Stephen & Linda Smith 
On Wednesday, September 5, 2018 9:17:29 PM MST Stephen & Linda Smith wrote:

> So two questions:
> 1)  why would git version 2.18.0 not appear to continue applying the
> patches.
> 
> 2) where do I find the command "git mailsplit".   The onlything in my
> installed tree is:
> 
Never mind, I downloaded each patch separately.

Mailsplit

2018-09-05 Thread Stephen & Linda Smith 
I thought I would use "git mailsplit" to split a mbox file (which downloaded 
from public inbox) so that I could attemp to resurrect a patch series for from 
a year ago.  

The motivation is that I downloaded the series [1] and applied to a tag from 
about the time period that the patch was sent out [2].  

The "git am -3 patch.mbox  quit 2/3 of the way though.   I resolved the fix. 
and ran "git am --continue" which didn't apply the rest of the patches in the 
mbox.

So two questions:
1)  why would git version 2.18.0 not appear to continue applying the patches.   

2) where do I find the command "git mailsplit".   The onlything in my 
installed tree is:

$ find  /usr/local/ -name '*mailsplit*'
/usr/local/share/doc/git-doc/git-mailsplit.txt
/usr/local/share/doc/git-doc/git-mailsplit.html
/usr/local/share/man/man1/git-mailsplit.1
/usr/local/libexec/git-core/git-mailsplit

sps

[1] 
https://public-inbox.org/git/1502914591-26215-1-git-send-email-martin@mail.zuhause/

[2] I wanted to make sure that I could apply back then before attempting to 
either apply to the latest git version or rebase to the latest git version.

Re: How to handle patch series conflicts

2018-09-05 Thread Stephen & Linda Smith 
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> I think that one that is not even in 'pu' hasn't been looked at for
> a long time; it is probably a good idea to discard and replace, if
> you have something working.

I submitted [1] over the weekend.  I will add a spelling error patch and then 
submit version 3 hopefully before the end of the day.   I am working on the 
test rename, but will wait to submit until after the wt-status.c patches cook 
and then go to mainline.   Rationale:   I haven't yet gone through the commit 
scripts to decided on the best proposed names.

[1] https://public-inbox.org/git/20180901235256.4260-1-isch...@cox.net/

Re: How to handle patch series conflicts

2018-09-05 Thread Stephen & Linda Smith 
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> I think that one that is not even in 'pu' hasn't been looked at for
> a long time; it is probably a good idea to discard and replace, if
> you have something working.

I submitted [1] over the weekend.  I will add a spelling error patch and then 
submit version 3 hopefully before the end of the day.   I am working on the 
test rename, but will wait to submit until after the wt-status.c patches cook 
and then go to mainline.   Rationale:   I haven't yet gone through the commit 
scripts to decided on the best proposed names.

[1] https://public-inbox.org/git/20180901235256.4260-1-isch...@cox.net/

How to handle patch series conflicts

2018-09-05 Thread Stephen & Linda Smith 
Junio -

On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
> > t7500-commit.sh
> > t7501-commit.sh
> > t7502-commit.sh
> > t7509-commit.sh
> 
> These seem to have organically grown and it is very likely that ones
> later introduced were added more from laziness.

How does the project prefer to handle patches that conflict.  Renaming t7501-
commit.sh will conflict with a patch set that I submitted over the weekend 
[1].  Should I treat them as totally separate? 

On Tuesday, September 4, 2018 3:36:11 PM MST Junio C Hamano wrote:
> * sl/commit-dry-run-with-short-output-fix (2018-07-30) 4 commits
>  . commit: fix exit code when doing a dry run
>  . wt-status: teach wt_status_collect about merges in progress
>  . wt-status: rename commitable to committable
>  . t7501: add coverage for flags which imply dry runs

I noted that this patch set is similar to the one that I just submitted.  Are 
you thinking of not using mine (in which case I will drop it)?  If not I will 
add a patch to fix the committable spelling[2] and re-roll.

[1] https://public-inbox.org/git/20180901235256.4260-1-isch...@cox.net/

Re: test files with same names?

2018-09-04 Thread Stephen & Linda Smith 
I don't mind doing this.

On Tuesday, September 4, 2018 10:27:26 AM MST Junio C Hamano wrote:
> Duy Nguyen  writes:
> > t2000-checkout-cache-clash.sh
> > t2001-checkout-cache-clash.sh
> 
> These date back to 368f99d5 ("[PATCH 2/2] The core GIT tests: recent
> additions and fixes.", 2005-05-13) which later were renamed by
> f50c9f76 ("Rename some test scripts and describe the naming
> convention", 2005-05-15).  One was about checking out a regular file
> to a path where a directory currently sits, and the other is about
> checking out a regular file that requires a parent directory at a
> path where a regular file currently occupies.  These days, I suspect
> that we would make these into a single "d/f conflict when checking
> files out" test script, and f50c9f76 might have been a good chance
> to do such a clean-up.  If somebody cares deeply enough, I do not
> mind seeing a belated clean-up, either.
> 
> > t7500-commit.sh
> > t7501-commit.sh
> > t7502-commit.sh
> > t7509-commit.sh
> 
> These seem to have organically grown and it is very likely that ones
> later introduced were added more from laziness.
> 
> If somebody wants to clean them up, probably the first thing to do
> is to study them to come up with a clear $test_description for each
> of them.  I think t7509 says --reset-author and it may have started
> as a test on that single feature, but it now covers other ways to
> set and/or preserve authorship information, so it may make sense to
> update its $test_description to "commit authorship" or something,
> for example.

Re: What's cooking in git.git (Aug 2018, #06; Wed, 29)

2018-09-02 Thread Stephen & Linda Smith 
On Wednesday, August 29, 2018 3:35:57 PM MST Junio C Hamano wrote:
> 
> * mk/use-size-t-in-zlib (2017-08-10) 1 commit
>  . zlib.c: use size_t for size
> 
>  The wrapper to call into zlib followed our long tradition to use
>  "unsigned long" for sizes of regions in memory, which have been
>  updated to use "size_t".
> 
>  Needs resurrecting by making sure the fix is good and still applies
>  (or adjusted to today's codebase).

This appears to be part of a large patch set. [1]  Does the entire patch set 
need revisiting or just the one for zlib.c?

sps

[1] 
https://public-inbox.org/git/1502914591-26215-1-git-send-email-martin@mail.zuhause/

Re: [PATCH v2 2/3] Add test for commit --dry-run --short.

2018-09-01 Thread Stephen & Linda Smith 
On Saturday, September 1, 2018 7:18:34 PM MST Eric Sunshine wrote:
> > diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> > @@ -682,4 +682,12 @@ test_expect_success '--dry-run with conflicts fixed
> > from a merge' ' +test_expect_failure '--dry-run --short' '
> > +   # setup two branches with conflicting information
> > +   # in the same file, resolve the conflict
> 
> What is this comment all about? It doesn't seem to have any relation
> to what the test itself is actually doing. (I see that it was copied
> from an earlier test in this script, but that doesn't help me
> understand what it is trying to say.)

Agreed.   

I saw your other email about not being worth a re-roll, but I've made the 
change locally in case Junio wants me to do so.  

Additionally if there are other comments I can wrap them into a single set.

Re: [PATCH 3/3] wt-status.c: Set the commitable flag in the collect phase.

2018-08-31 Thread Stephen & Linda Smith 
On Friday, August 31, 2018 9:54:50 AM MST Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason  writes:
> >> Leave the setting of the commitable flag in show_merge_in_progress. If
> >> a check for merged commits is moved to the collect phase then other
> >> --dry-run tests fail.
> 
> "Some tests fail" is not a good explanation why you keep the setting
> of commitable bit in the "show" codepath.  The test coverage may not
> be thorough, and the tests that fail might be expecting wrong things.
> 
I didn't figure it was, but I haven't yet figured out how to explain what what 
I saw last evening.   I wanted to send something out to get feedback from 
someone who may know the code far better than I.

> The change in this patch makes the internal "diff-index" invocation
> responsible for setting the commitable bit.  This is better for non
> merge commits than the current code because the current code only
> sets the commitable bit when longstatus is asked for (and the code
> to show the longstatus detects changes to be committed), so the
> short-form will not have chance to set the bit, but the internal
> "diff-index" is what determines if the resulting commit would have
> difference relative to the HEAD, so it is a better place to make
> that decision.
> 
> Merge commits need to be allowed even when the resulting commit
> records a tree that is identical to that of the current HEAD
> (i.e. we merged a side branch, but we already had all the necessary
> changes done on it).  So it is insufficient to let "diff-index"
> invocation to set the committable bit.  Is that why "other --dry-run
> tests fail"?  What I am getting at is to have a reasonable "because
> ..."  to explain why "other --dry-run tests fail" after it, to make
> it clear to the readers that the failure is not because tests are
> checking wrong things but because a specific condition 
thatwt_status_collect(), isYes
> expeted from the code gets violated if we change the code in
> show_merge_in_progress() function.
Agreed.  I'm just green at this code base, and so don't quite know what I 
should see as opposed to what I do see.

> 
> That brings us to another point.  Is there a case where we want to
> see s->commitable bit set correctly but we do not make any call to
> show_merge_in_progress() function?  It is conceivable to have a new
> "git commit --dry-run --quiet [[--] ]" mode that is
> totally silent but reports if what we have is committable with the
> exit status, and for that we would not want to call any show_*
> functions.  That leads me to suspect that ideally we would want to
> see wt_status_collect_changes_index() to be the one that is setting
> the commitable bit.  Or even its caller wt_status_collect(), which
> would give us a better chance of being correct even during the
> initial commit.  For the "during merge" case, we would need to say
> something like
> 
>   if (state->merge_in_progress && !has_unmerged(s))
>   s->commitable = 1;
> 
I placed the following  in wt_status_collect() last evening, and received 
errors from three early tests in 7501-commit.sh.   Thanks for a hint.

if (!has_unmerged(s))
s->commitable = 1;

Maybe the missing first condition was what I needed.

Which leads me to asking:  Do you want a preparatory patch moving 
has_unmerged() further up in the file before adding a reference to 
has_unmerged() in wt_status_collect().  

> but the "state" thing is passed around only among the "print/show"
> level of functions in the current code.  We might need to merge that
> into the wt_status structure to pass it down to the "collect" phase
> at the lower level before/while doing so.  I dunno.
Would you explain what you  are thinking for passing moving the "stat" think 
into wt_status.I haven't figured out how the "collect" sequence, relates 
to the "print/show" squence.

> 
> Thanks for working on this.
I decided sometime back to work on something I didn't know using a process I 
don't normally use to broaden my experience.   I'm enjoying this and hope you 
don't mind lots of questions from someone new.

sps

Re: [PATCH 2/3] Add test for commit --dry-run --short.

2018-08-31 Thread Stephen & Linda Smith 
On Friday, August 31, 2018 9:26:02 AM MST Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason  writes:
> > 
> > Ditto my comment on 1/3 on this. I.e. this changes the failing tests in
> > this series from 2 to 3.
> 
> Correct.  Thanks for helping Stephen on this topic.

I wasn't sure how this situation was normally handled.  I will update when I 
re-roll changes for wt-status.c.

Re: Missing Tagger Entry

2018-08-29 Thread Stephen & Linda Smith 
On Wednesday, August 29, 2018 7:43:05 PM MST Ramsay Jones wrote:
> 
> Hope this helps.
> 
> ATB,
> Ramsay Jones

I was working on the patch for wt-status.c and thought I screwed up my git 
database.  So I ran fsck and ran into the tag issue.

Thanks
sps

Missing Tagger Entry

2018-08-29 Thread Stephen & Linda Smith 
I am getting the following warning when runing a git fsck command against tag 
v0.99.

$ git --version
git version 2.18.0

$ git fsck
checking object directories: 100% (256/256), done.
warning in tag d6602ec5194c87b0fc87103ca4d67251c76f233a: missingTaggerEntry: 
invalid format - expected 'tagger' line
Checking objects: 100% (254339/254339), done.
Checking connectivity: 254329, done.

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

2018-08-22 Thread Stephen & Linda Smith 
> > On Tuesday, February 16, 2016 8:33:54 PM MST Junio C Hamano wrote:
> Wow, that's quite an old discussion ;-)
It wasn't intended to be so

> After these:

> tells me that "--short" still does not notice that there _is_
> something to be committed, either with an ancient version like
> v2.10.5 or more modern versions of Git.  The "long" version exits
> with 0, while "--short" one exists with 1.

$ git commit --dry-run --short; echo $?
A  a-new-file
0

$ git commit --dry-run --short; echo $?
A  a-new-file
1

> 
> So...?

For me it is the return code that is faulty   Starting to investigate.   
Thanks

References to old messages

2016-12-21 Thread Stephen & Linda Smith 
I want to pick up work  on a patch that I was working on previously.  

I had been told to reference (i.e. footnote) a gmane URL.  With that service 
no longer being being online, what is the preferred method footnoting?

sps

Re: Allow "git shortlog" to group by committer information

2016-12-15 Thread Stephen & Linda Smith 
On Thursday, December 15, 2016 5:39:53 PM MST Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 4:19 PM, Junio C Hamano  wrote:
> 
> Sorry, I'll just re-send it without the attachment. I prefer inline
> myself, but I thought you didn't care (and gmail makes it
> unnecessarily hard).
> 
> Linus

Why does gmail make it unnecessarily hard?  

I thought that a good percentage of the kernel maintainers use git send-email.  
 
what would make that command easier to use with gmail?

sps

Re: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

2016-05-10 Thread Stephen & Linda Smith 
On Tuesday, February 16, 2016 07:33:54 PM Junio C Hamano wrote:
> > ---
> 
> I think I mislead you into a slightly wrong direction.  While the
> single liner does improve the situation, I think this is merely a
> band-aid upon closer inspection.  For example, if you changed your
> "commit --dry-run" in your test to "commit --dry-run --short", you
> would notice that the test would fail.
> 
I understand.

> In fact, "commit --dry-run" is already broken without this "a merge
> ends up in a no-op" corner case.  The management of s->commitable
> flag and dry_run_commit() that uses it are unfortunately more broken
> than I originally thought.
> 
> If we check for places where s->committable is set, we notice that
> there is only one location: wt_status_print_updated().  This function
> runs an equivalent of "diff-index --cached" and flips s->committable
> on when it sees any difference.
> 
> This function is only called from wt_status_print(), which in turn
> is only called from run_status() in commit.c when the status format
> is unspecified or set to STATUS_FORMAT_LONG.
> 
> So if you do this:
> 
> $ git reset --hard HEAD
> $ >a-new-file && git add a-new-file
> $ git commit --dry-run --short; echo $?
> 
> you'd get "No, there is nothing interesting to commit", which is
> clearly bogus.
> 
> I said s->committable is flipped on only when there is any change in
> "diff-index --cached".  There is nothing that flips it off, by
> noticing that there are unmerged paths, for example.  This is
> another brokenness around "git commit --dry-run".  Imagine that you
> are in a middle of a conflicted cherry-pick.  You did "git add" on a
> resolved path and you still have another path whose conflict has not
> been resolved.  If you run a "git commit --dry-run", you will hear
> "Yes, you can make a meaningful commit", which again is clearly
> bogus.
> 
Makes sense.

> These things need to be eventually fixed, and I think the fix will
> involve revamping how we compute s->committable flag.  Most likely,
> we won't be doing any of that in any wt_status function whose name
> has "print" or "show" in it.  As the original designer of the wt_*
> suite (before these multiple output formats are added), I would say
> everything should happen inside the "collect" phase, if we wanted to
> make s->committable bit usable.
Tonight I started work on a patch to remove the two locations where 
committable was set in  the *print* and *show* functions.  

I believe that what you mean by the "collect" phase is the set of functions 
that are in wt_status.c and have collect in the function name.

> 
> So in the sense, eventually the code updated by this patch will have
> to be discarded when we fix the "commit --dry-run" in the right way,
> but in the meantime, the patch does not make things worse, so let's
> think about queuing it as-is for now as a stop-gap measure.
> 
I'm happy with moveing the patch from pu (where it is now) to next.   I've
re-started my work on this.

> 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: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

2016-02-16 Thread Stephen & Linda Smith 
On Tuesday, February 16, 2016 07:33:54 PM Junio C Hamano wrote:
> "Stephen P. Smith"  writes:
> 
> > The 'commit --dry-run' and commit return values differed if a
> > conflicted merge had been resolved and the commit would be the same as
> > the parent.
> >
> > Update show_merge_in_progress to set the commitable bit if conflicts
> > have been resolved and a merge is in progress.
> >
> > Signed-off-by: Stephen P. Smith 
> > ---
> 
> I think I mislead you into a slightly wrong direction.  While the
> single liner does improve the situation, I think this is merely a
> band-aid upon closer inspection.  For example, if you changed your
> "commit --dry-run" in your test to "commit --dry-run --short", you
> would notice that the test would fail.
> 
> In fact, "commit --dry-run" is already broken without this "a merge
> ends up in a no-op" corner case.  The management of s->commitable
> flag and dry_run_commit() that uses it are unfortunately more broken
> than I originally thought.
> 
> If we check for places where s->committable is set, we notice that
> there is only one location: wt_status_print_updated().  This function
> runs an equivalent of "diff-index --cached" and flips s->committable
> on when it sees any difference.
> 
> This function is only called from wt_status_print(), which in turn
> is only called from run_status() in commit.c when the status format
> is unspecified or set to STATUS_FORMAT_LONG.
> 
> So if you do this:
> 
> $ git reset --hard HEAD
> $ >a-new-file && git add a-new-file
> $ git commit --dry-run --short; echo $?
> 
> you'd get "No, there is nothing interesting to commit", which is
> clearly bogus.
> 
> I said s->committable is flipped on only when there is any change in
> "diff-index --cached".  There is nothing that flips it off, by
> noticing that there are unmerged paths, for example.  This is
> another brokenness around "git commit --dry-run".  Imagine that you
> are in a middle of a conflicted cherry-pick.  You did "git add" on a
> resolved path and you still have another path whose conflict has not
> been resolved.  If you run a "git commit --dry-run", you will hear
> "Yes, you can make a meaningful commit", which again is clearly
> bogus.
> 
> These things need to be eventually fixed, and I think the fix will
> involve revamping how we compute s->committable flag.  Most likely,
> we won't be doing any of that in any wt_status function whose name
> has "print" or "show" in it.  As the original designer of the wt_*
> suite (before these multiple output formats are added), I would say
> everything should happen inside the "collect" phase, if we wanted to
> make s->committable bit usable.
> 
> So in the sense, eventually the code updated by this patch will have
> to be discarded when we fix the "commit --dry-run" in the right way,
> but in the meantime, the patch does not make things worse, so let's
> think about queuing it as-is for now as a stop-gap measure.
> 
H  that makes sense.   

Let me fix the commit message per what I told Philip and then 
I will start working on a rework of the commitable bit with 
this in mind as a follow on patch.  

> 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

--
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: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

2016-02-16 Thread Stephen & Linda Smith 
On Tuesday, February 16, 2016 04:26:38 PM Stephen & Linda Smith wrote:
> On Tuesday, February 16, 2016 01:54:48 PM Junio C Hamano wrote:
> > "Philip Oakley" <philipoak...@iee.org> writes:
> > 
> > >>It appeared that the conditional for 'Reject an attempt to record a
> > >>non-merge empty commit without * explicit --allow-empty.' could be
> > >>simplified after adding this patch.
> > >>
> > >>This change can't be propagated to the conditional because it allows
> > >>a commit that was previously disallowed.
> > 
> > This last sentence sounds somewhat worrysome.  Does that mean some
> > commit that was previously disallowed (which ones?) is still
> > forbidden by "commit" without "--dry-run" (which is correct--we are
> > not interested in changing the behaviour of the main codepath), but
> > "--dry-run", even with this update, will say "OK you will make a
> > meaningful commit" by exiting with 0 for such disallowed commit?
> I tried to think of a better set of wording.  Finally I decided to make it 
> part of the note 
> rather than the commit message so that it could be debated as part of the 
> review 
> but not be part of the commit record for the line being changed.
> 
> The patch doesn't change behaviour other than the dry-run return code 
> which now matches the return code of commit.  The one line change is not 
> changing the
> main code path behaviour
> 
I am not adverse to moving the change to dry_run_commit() proper, 
but that would mean a slightly larger patch.

> The main code path for the case being fixed executes through the main code 
> path 
> successfully returning zero.  The ''--dry-run' was predicitng failure if a 
> script was 
> checking the return code, but successs if looking at the messages.
> 
> The final couple of paragraphs explain why I chose not to change the if() 
> statement. 
> The reason I didn't is so that expected behaviour is maintained.
> 
> The condition that can not be removed in the if is the 'whence != 
> FROM_MERGE'.   Removing 
> that caused t7502 to generate errors.   Therefore I left ' if (!commitable && 
> whence != FROM_MERGE 
> && !allow_empty &&  !(amend && is_a_merge(current_head)))' in the commit.c 
> file.
> 
> --
> 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

--
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: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

2016-02-16 Thread Stephen &amp; Linda Smith 
On Tuesday, February 16, 2016 08:20:43 AM Philip Oakley wrote:
> From: "Stephen P. Smith" 
> > The 'commit --dry-run' and commit return values differed if a
> 
> Should this have quotes around the second 'commit' as they both refer to the 
> command, rather than the action?
OK

> 
> > conflicted merge had been resolved and the commit would be the same as
> > the parent.
> >
> > Update show_merge_in_progress to set the commitable bit if conflicts
> > have been resolved and a merge is in progress.
> >
> > Signed-off-by: Stephen P. Smith 
> > ---
> >
> > Notes:
> >In the original report when the dry run switch was passed and after
> >the merge commit was resolved head and index matched leading to a
> >returned value of 1. [1]
> >
> >If the dry run switch was not passed, the commit would succeed to
> >correctly record the resolution.
> >
> >The result was that a dry run would report that there would be a
> >failure, but there really isn't a failure if the commit is actually
> >attemped.
> >
> >[1] $gmane/276591
> >
> >It appeared that the conditional for 'Reject an attempt to record a
> >non-merge empty commit without * explicit --allow-empty.' could be
> >simplified after adding this patch.
> >
> >This change can't be propagated to the conditional because it allows
> >a commit that was previously disallowed.
> >
> > t/t7501-commit.sh | 20 
> > wt-status.c   |  1 +
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
> > index 63e0427..363abb1 100755
> > --- a/t/t7501-commit.sh
> > +++ b/t/t7501-commit.sh
> > @@ -587,4 +587,24 @@ test_expect_success '--only works on to-be-born 
> > branch' '
> >  test_cmp expected actual
> > '
> >
> > +test_expect_success '--dry-run with conflicts fixed from a merge' '
> > + # setup two branches with conflicting information
> > + # in the same file, resolve the conflict,
> > + # call commit with --dry-run
> > + echo "Initial contents, unimportant" >test-file &&
> > + git add test-file &&
> > + git commit -m "Initial commit" &&
> > + echo "commit-1-state" >test-file & to the list and the cc's. Junio 
> > also had 
> > + git commit -m "commit 1" -i test-file &&
> > + git tag commit-1 &&
> > + git checkout -b branch-2 HEAD^1 &&
> > + echo "commit-2-state" >test-file &&
> > + git commit -m "commit 2" -i test-file &&
> > + ! $(git merge --no-commit commit-1) &&
> > + echo "commit-2-state" >test-file &&
> > + git add test-file &&
> > + git commit --dry-run &&
> > + git commit -m "conflicts fixed from merge."
> > +'
> > +
> > test_done
> > diff --git a/wt-status.c b/wt-status.c
> > index ab4f80d..1374b48 100644
> > --- a/wt-status.c
> > +++ b/wt-status.c
> > @@ -950,6 +950,7 @@ static void show_merge_in_progress(struct wt_status 
> > *s,
> >  status_printf_ln(s, color,
> >  _("  (fix conflicts and run \"git commit\")"));
> >  } else {
> > + s-> commitable = 1;
> >  status_printf_ln(s, color,
> >  _("All conflicts fixed but you are still merging."));
> >  if (s->hints)
> >
> > --
> 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

--
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: [PATCH] wt-status.c: set commitable bit if there is a meaningful merge.

2016-02-16 Thread Stephen &amp; Linda Smith 
On Tuesday, February 16, 2016 01:54:48 PM Junio C Hamano wrote:
> "Philip Oakley"  writes:
> 
> >>It appeared that the conditional for 'Reject an attempt to record a
> >>non-merge empty commit without * explicit --allow-empty.' could be
> >>simplified after adding this patch.
> >>
> >>This change can't be propagated to the conditional because it allows
> >>a commit that was previously disallowed.
> 
> This last sentence sounds somewhat worrysome.  Does that mean some
> commit that was previously disallowed (which ones?) is still
> forbidden by "commit" without "--dry-run" (which is correct--we are
> not interested in changing the behaviour of the main codepath), but
> "--dry-run", even with this update, will say "OK you will make a
> meaningful commit" by exiting with 0 for such disallowed commit?
I tried to think of a better set of wording.  Finally I decided to make it part 
of the note 
rather than the commit message so that it could be debated as part of the 
review 
but not be part of the commit record for the line being changed.

The patch doesn't change behaviour other than the dry-run return code 
which now matches the return code of commit.  The one line change is not 
changing the
main code path behaviour

The main code path for the case being fixed executes through the main code path 
successfully returning zero.  The ''--dry-run' was predicitng failure if a 
script was 
checking the return code, but successs if looking at the messages.

The final couple of paragraphs explain why I chose not to change the if() 
statement. 
The reason I didn't is so that expected behaviour is maintained.

The condition that can not be removed in the if is the 'whence != FROM_MERGE'.  
 Removing 
that caused t7502 to generate errors.   Therefore I left ' if (!commitable && 
whence != FROM_MERGE 
&& !allow_empty &&  !(amend && is_a_merge(current_head)))' in the commit.c file.

--
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: Bug report: 'git commit --dry-run' corner case: returns error ("nothing to commit") when all conflicts resolved to HEAD

2016-02-11 Thread Stephen &amp; Linda Smith 
On Monday, February 08, 2016 06:55:17 PM Stephen & Linda Smith wrote:
> > #!/bin/bash
> > mkdir test-repository || exit 1
> > cd test-repository
> > git init
> > echo "Initial contents, unimportant" > test-file
> > git add test-file
> > git commit -m "Initial commit"
> > echo "commit-1-state" > test-file
> > git commit -m "commit 1" -i test-file
> > git tag commit-1
> > git checkout -b branch-2 HEAD^1
> > echo "commit-2-state" > test-file
> > git commit -m "commit 2" -i test-file
> > 
> > # Creates conflicted state.
> > git merge --no-commit commit-1
> > 
> > # Resolved entirely to commit-2, aka HEAD.
> > echo "commit-2-state" > test-file
> > # If we'd set to commit-1=state, all would work as expected (changes vs 
> > HEAD).
> > git add test-file
> > 
> > # =  Bug is here.
> > git commit --dry-run && echo "Git said something to commit" \
> > || echo "Git said NOTHING to commit"

With the  '--dry-run' switch, dry_run_commit() is called which returns 1 
since run_status() is returning the wt_status commitable field which has a 
value of 0.

That field is only set in one place (wt_status_print_updated) which isn't 
getting called
directly or indirectly by run_status.   I checked this by code inspection as 
well as by 
instrumenting the code.

I'm not sure that we want to add a call to wt_status_print_updated in 
run_status since 
I don't believe we want the print statements.   An alternative might be to 
create a
new function.

> > 
> > git commit -m "Something to commit after all" && echo "Commit went through"
> > 
> > git log --pretty=oneline
--
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: Bug report: 'git commit --dry-run' corner case: returns error ("nothing to commit") when all conflicts resolved to HEAD

2016-02-08 Thread Stephen &amp; Linda Smith 
Ovidiu Gheorghioiu  wrote:
>  Hi git guys,
>
> The bug is fairly simple: if we have a conflicted merge, AND all the
> conflicts have been resolved to the version in HEAD, the commit
> --dry-run error code says nothing to commit. As expected, git commit
> goes through.
> 
> The commit message IS correct (-ish), just not the error code:
> 
> """
> All conflicts fixed but you are still merging.
>   (use "git commit" to conclude merge)
> 
> nothing to commit, working directory clean
> """
> 
> The script below demonstrates the problem; version tested was 2.5.0.
> Let me know if you need any more details.
> 
> Best,
> Ovidiu
> 
> --
> #!/bin/bash
> mkdir test-repository || exit 1
> cd test-repository
> git init
> echo "Initial contents, unimportant" > test-file
> git add test-file
> git commit -m "Initial commit"
> echo "commit-1-state" > test-file
> git commit -m "commit 1" -i test-file
> git tag commit-1
> git checkout -b branch-2 HEAD^1
> echo "commit-2-state" > test-file
> git commit -m "commit 2" -i test-file
> 
> # Creates conflicted state.
> git merge --no-commit commit-1
> 
> # Resolved entirely to commit-2, aka HEAD.
> echo "commit-2-state" > test-file
> # If we'd set to commit-1=state, all would work as expected (changes vs HEAD).
> git add test-file
> 
> # =  Bug is here.
> git commit --dry-run && echo "Git said something to commit" \
> || echo "Git said NOTHING to commit"
> 
> git commit -m "Something to commit after all" && echo "Commit went through"
> 
> git log --pretty=oneline
> 
> cd ..

I've reproduced the bug with git 2.7.1. [1]
I plan on adding a test case and a patch to fix this.

[1] http://article.gmane.org/gmane.comp.version-control.git/276591

I would have responded to the original email but 
the gmane "follow-up" is not sending out the email.


--
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: Picking up old threads/patches

2016-01-07 Thread Stephen &amp; Linda Smith 
On Thursday, January 07, 2016 03:03:50 AM Jeff King wrote:
> If it's an ancient thread, it's not a big deal to just start a new
> thread (especially if you reference the old one in the text so people
> can dig it up if they really care).
> 
> But for reference, you can add `/raw` to the end of a gmane article URL
> to get all the headers. E.g.:
> 
>   $ gmane=http://article.gmane.org/gmane.comp.version-control.git
>   $ curl -s $gmane/271213/raw | grep -i ^message-id:
>   Message-ID: 
> 
> 

Thank you.

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

Picking up old threads/patches

2016-01-06 Thread Stephen &amp; Linda Smith 
> If Will isn't interested in finishing these two patches I will pick them 
> up [ ($gmane/271213), ($gmane/272180) ]
> 
> After that I will check look at some of the others for which you've 
> asked for help.

I started work on both of this this evening.   Since I do not have the 
original emails I don't have the Message ID's which would make it 
to use with the git send-email command.   Do either of you have the 
message ID's?


--
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: Picking up old threads/patches

2016-01-06 Thread Stephen &amp; Linda Smith 
> If Will isn't interested in finishing these two patches I will pick them 
> up [ ($gmane/271213), ($gmane/272180) ]
> 
> After that I will check look at some of the others for which you've 
> asked for help.
 
I started work on both of these rerolls this evening.   Since I do not have the 
original emails I don't have the Message ID's which  would allow me 
to add to the threads with the git send-email command.   Do either of you have 
the 
message ID's?

 

--
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 (Jan 2016, #01; Mon, 4)

2016-01-04 Thread Stephen &amp; Linda Smith 
On Monday, January 04, 2016 03:44:33 PM Junio C Hamano wrote:
>  Becoming tired of waiting for a reroll.
>  ($gmane/271213).
>  Anybody wants to help rerolling this?  Otherwise will discard.



> Becoming tired of waiting for a reroll.
>  Anybody wants to help rerolling this?  Otherwise will discard.
 > ($gmane/272180).

What do you mean by rerolling this?  If you mean that you would like 
someone to pick up the patch and try and get it though then I don't mind 
helping.
Of course if the original authors are wanting to finish, then I will look for 
something else.

For my education, how does this affect the sign-off proceedure?

sps
--
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 (Jan 2016, #01; Mon, 4)

2016-01-04 Thread Stephen &amp; Linda Smith 
On Monday, January 04, 2016 07:36:05 PM Junio C Hamano wrote:
> Stephen & Linda Smith <isch...@cox.net> writes:
> 
> > On Monday, January 04, 2016 03:44:33 PM Junio C Hamano wrote:
> >>  Becoming tired of waiting for a reroll.
> >>  ($gmane/271213).
> >>  Anybody wants to help rerolling this?  Otherwise will discard.
> >
> > 
> >
> >> Becoming tired of waiting for a reroll.
> >>  Anybody wants to help rerolling this?  Otherwise will discard.
> >  > ($gmane/272180).
> >
> > What do you mean by rerolling this?  If you mean that you would
> > like someone to pick up the patch and try and get it though then I
> > don't mind helping.
> 
> More or less.  I do not mind if these topics disappeared, either,
> but we have spent review and discussion bandwidth for these
> unfinished topics and we may want to take them to the completion.
> 
> > For my education, how does this affect the sign-off proceedure?
> 
> Depending on the extent of changes from the original version, either
> you take the authorship (with comment in the log message saying that
> it is based on Such and Such's patches) or you still keep them as
> the author (with comment in the log message saying that you extended
> it in such and such way).  In either case, as long as their original
> remains in the resulting patch, you retain their Sign-off and then
> add your Sign-off at the end.
> 
> If you take the ideas from their series and rewrite everything from
> scratch, you would take the authorship, with comment in the log
> message saying that you took inspiration from Such and Such's
> patches, and have only your Sign-off.
> 
> 

If Will isn't interested in finishing these two patches I will pick them 
up [ ($gmane/271213), ($gmane/272180) ]

After that I will check look at some of the others for which you've 
asked for help.


--
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: [PATCH V2] user-manual: add addition gitweb information

2015-12-30 Thread Stephen &amp; Linda Smith 
On Wednesday, December 30, 2015 03:29:09 PM Junio C Hamano wrote:
> "Stephen P. Smith"  writes:
> 
> >  The gitweb cgi script provides users an easy way to browse your
> > -project's files and history without having to install Git; see the file
> > -gitweb/INSTALL in the Git source tree for instructions on setting it up.
> > +project's revisions, file contents and logs without having to install
> > +Git. Features like RSS/Atom feeds and blame/annotation details may
> 
> Thanks.  Was there a reason to rewrite "files and history" into
> "revisions, file contents and logs"?  The words "revisions" and
> "logs" both refer to the same thing and "history" is a good word for
> it already, so I am puzzled.  No strong objection, though...
> 

"revisions, file contents and logs was in the second sentence of the first 
patch.
"files and history" was in the first sentence of the first patch.

When I was getting rid of the duplication I decided that "revisions, file 
contents and logs".   
As a secondary reason that is the wording in gitweb.txt.



--
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: [PATCH V2] user-manual: add addition gitweb information

2015-12-30 Thread Stephen &amp; Linda Smith 
On Wednesday, December 30, 2015 03:29:09 PM Junio C Hamano wrote:
 > "Stephen P. Smith"  writes:
 > 
 > >  The gitweb cgi script provides users an easy way to browse your
 > > -project's files and history without having to install Git; see the file
 > > -gitweb/INSTALL in the Git source tree for instructions on setting it up.
 > > +project's revisions, file contents and logs without having to install
 > > +Git. Features like RSS/Atom feeds and blame/annotation details may
 > 
 > Thanks.  Was there a reason to rewrite "files and history" into
 > "revisions, file contents and logs"?  The words "revisions" and
 > "logs" both refer to the same thing and "history" is a good word for
 > it already, so I am puzzled.  No strong objection, though...
 > 

[Re-worded my explanation.]
 
"revisions, file contents and logs was in the second sentence of the first 
patch.
"files and history" was in the first sentence of the first patch.

When I was getting rid of the duplication I decided that "revisions, file 
contents 
and logs" was a little more explicit and so decided to keep that wording.

As a secondary reason that is the wording in gitweb.txt.
--
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: [PATCH V5 2/2] user-manual: add section documenting shallow clones

2015-12-29 Thread Stephen &amp; Linda Smith 
On Tuesday, December 29, 2015 11:24:00 AM Junio C Hamano wrote:
> "Stephen P. Smith"  writes:
> 
> > Rather than merely pointing readers at the 1.5 release notes to
> > learn about shallow clones, document them formally.
> >
> > Signed-off-by: Stephen P. Smith 
> > ---
> 
> Thanks.  I do not think the reference to RelNotes were meant for the
> end-user readers, though.  That was a hint for whoever is working to
> clear the "todo" items from that list i.e. you ;-> ).

Actually that was a suggested update[1].   Do you still think I should replace 
it?

[1] http://article.gmane.org/gmane.comp.version-control.git/282831
> 
> > +[[how-to-get-a-git-repository-with-minimal-history]]
> > +How to get a Git repository with minimal history
> > +
> > +
> > +A <>, with its truncated
> > +history, is useful when one is interested only in recent history
> > +of a project and getting full history from the upstream is
> > +expensive.
> > +
> > +A <> is created by specifying
> > +the linkgit:git-clone[1] `--depth` switch. The depth can later be
> > +changed with the linkgit:git-fetch[1] `--depth` switch, or full
> > +history restored with `--unshallow`.
> > +
> > +Merging inside a <> will work as long
> > +as the merge base is in the resent history.  If the merge base is not
> 
> recent?

I had that fixed and then managed to corrupt my working branch losing the 
change.

> 
> > +present then the merge would be of un-related histories.  This
> > +limitaion is fundamental and will not be removed.
> 
> I think "fundamental and will not change" is much less important
> than the "huge conflicts, making the result of 'clone --depth='
> not very useful to perform merges in", which is what the users would
> need to know before deciding to use this feature.

OK

> 
> > +
> >  [[sharing-development-examples]]
> >  Examples
> >  
> > @@ -4645,9 +4664,6 @@ standard end-of-chapter section?
> >  
> >  Include cross-references to the glossary, where appropriate.
> >  
> > -Document shallow clones?  See draft 1.5.0 release notes for some
> > -documentation.
> > -
> >  Add a section on working with other version control systems, including
> >  CVS, Subversion, and just imports of series of release tarballs.
> --
> 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

--
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: [PATCH] user-manual: remove temporary branch entry from todo list

2015-12-28 Thread Stephen &amp; Linda Smith 
On Monday, December 28, 2015 09:29:13 AM Junio C Hamano wrote:
> Stephen & Linda Smith <isch...@cox.net> writes:
> 
> > I think that this is a stale todo.   
> >  
> > The only place there is a mention of temporary branches (which is
> > then parenthetically called a topic branch) is in relation to how
> > Tony Luck organizes his work.  Additionally there is already a
> > subsection on using a detatched head ("Examining an old version
> > without creating a new branch).
> 
> I suspect that you stared at the output from "git grep" for
> "temporary" or even "temporary branch" and further I suspect that
> the experience blinded you.
> 
> The two lines in that todo item were first introduced at d5cd5de4
> (Documentation: begin discussion of git-remote in user manual,
> 2007-01-09), and then were updated at b181d57f (user-manual:
> reorganize fetch discussion, add internals, etc., 2007-01-27).  In
> between these two, the lines were rewrapped at 2f99710c
> (user-manual: rewrap, fix heading levels, 2007-01-14) but that
> commit was purely cosmetic.
> 
> When the todo item was introduced, it ended with a full-stop; the
> update changed it to a question mark, which I read it as hinting
> that the item might not be a good change.
> 
> The output from
> 
> $ git diff -U40 d5cd5de4 b181d57f Documentation/user-manual.txt
> 
> gives us a fairly good answer.  When the todo item was introduced,
> the "beginning" section was titled "Repositories and Branches", and
> showed you how to clone the Linux kernel in its first subsection,
> and then the next subsection showed "How to check out a different
> version", and showed that "git checkout -b new v2.6.13", followed by
> "git reset --hard v2.6.17", are the commands to use for sightseeing
> the project's landmarks.
> 
> The "new" is used as a temporary branch in the context of that
> example; the user is not building anything on top of these commits,
> the use of a named branch is ephemeral and the only reason a named
> branch is used is because the detached HEAD was a fairly new
> invention, introduced at c847f537 (Detached HEAD (experimental),
> 2007-01-01) and was merged to the mainline at c388761c (Merge branch
> 'jc/detached-head', 2007-01-11).
> 
> After commit b181d57f, aka "Let's keep the todo item for now, but I
> am no longer sure if it is a good idea so end it with a question
> mark", the "beginning" is a new section called "Git Quick Start",
> but the same "git checkout -b new v2.6.15" for sightseeing appears
> in this new section.
> 
> Another thing to notice is that the "temporary branch" you found in
> "git grep" about Tony's workflow did not exist in the user-manual
> back in these days.  It was added to the user-manual at 9e2163ea
> (user-manual: move howto/using-topic-branches into manual,
> 2007-05-13), so the todo item couldn't possibly have been referring
> to that example.
> 
> >> > -Simplify beginning by suggesting disconnected head instead of
> >> > -temporary branch creation?
> >> > -
> >> 
> >> What does "beginning" refer to in this sentence, though?
> >
> > I had that question too even after looking at the 2007 version of the 
> > manual.
> >> 
> >> After a quick reading of the beginning part of the document, I am
> >> getting the impression that it refers to the use of the 'new'
> >> branch, which is initially created out of v2.6.13 and then later
> >> reset to v2.6.17 while the user is in the sightseeing mode.  And
> >> this way of working _is_ a remnant from the days back when detached
> >> HEAD was not with us.
> >> 
> >> It is a completely separate matter if it is a good idea to teach
> >> detached HEAD that early in the tutorial, though.  
> >  
> > So are you suggesting a move of the section further down?   
> > Or are you suggesting that that is excised from the manual?
> 
> Neither.  Because the current text does not teach detached HEAD
> early in the tutorial, I see no need to move any section down, or
> excising a section.
> 
> >> So "remove the task because detached HEAD is a bit too weird
> >> thing to learn in that early stage in the learning curve"
> >> (i.e. the latter reason) might apply.
> >  
> > Could it be there are two reasons to remove the todo?
> 
> There could be, but I do not think it is the case here.
> 
> I do not think "it was already done" is a valid reason for removing
> this todo item, as I do not think it was done yet.
> 
> I think the only possible reason to remove that todo item is because
> teaching detached HEAD that early in the user manual gives a bit too
> steep learning curve--and I do not disagree with that justification.

I will rework the patch using the above analysis in the commit message.   Of
course I will rewrite for readability.



--
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: [PATCH V4 2/2] user-manual: add section documenting shallow clones

2015-12-28 Thread Stephen &amp; Linda Smith 
On Monday, December 28, 2015 02:57:47 PM Junio C Hamano wrote:
> "Stephen P. Smith"  writes:
> 
> > Rather than merely pointing readers at the 1.5 release notes to
> > learn about shallow clones, document them formally.
> >
> > Signed-off-by: Stephen P. Smith 
> > ---
> >
> >  I replaced the paragraphs that I wrote with Eric Shunshine's since it
> >  was cleaner.
> >
> >  I like the idea of linking to the preceeding effort, but gmane.org is
> >  currently undergoing maintance and therefore giving me errors when I
> >  attempt to access it.
> >
> >  Documentation/user-manual.txt | 17 ++---
> >  1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index 1c790ac..5c13683 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -2128,6 +2128,20 @@ The gitweb cgi script provides users an easy way to 
> > browse your
> >  project's files and history without having to install Git; see the file
> >  gitweb/INSTALL in the Git source tree for instructions on setting it up.
> >  
> > +[[how-to-get-a-git-repository-with-minimal-history]]
> > +How to get a Git repository with minimal history
> > +
> > +
> > +A <>, with its truncated
> > +history, is useful when one is interested only in recent history
> > +of a project and getting full history from the upstream is
> > +expensive.
> > +
> > +A <> is created by specifying
> > +the linkgit:git-clone[1] `--depth` switch. The depth can later be
> > +changed with the linkgit:git-fetch[1] `--depth` switch, or full
> > +history restored with `--unshallow`.
> > +
> >  [[sharing-development-examples]]
> >  Examples
> >  
> 
> OK.
> 
> > @@ -4645,9 +4659,6 @@ standard end-of-chapter section?
> >  
> >  Include cross-references to the glossary, where appropriate.
> >  
> > -Document shallow clones?  See draft 1.5.0 release notes for some
> > -documentation.
> > -
> 
> The 1.5.0 release notes describe three limitations that was present
> back in the day.  I think the first two have been lifted (I am not
> sure if it is throughly tested and shown to be bulletproof, though),
> but the third limitation is fundamental and not something that will
> ever be "fixed".  It probably is a good idea to add it here to avoid
> hurting unsuspecting new users.
> 

I had thought about putting in warnings in the user's manual (and even wrote up 
a 
paragraph) but then decided to remove it.  My rationale was that there are 
warnings/restrictions elsewhere in the documentation but I wasn't finding any 
in the user manual.  Thanks for changing my mind.

> I notice that this section uses "a shallow clone" as a noun that
> refers to a repository that has incomplete history--it is a synonym
> to "a shallow repository", but more explicitly conveys the fact that
> its cauterised history was obtained originally from elsewhere.
> 
> And I think that is a good use of the word, but I am not sure if
> the phrasing used in your [1/2] is consistent with it:
> 
> +[[def_shallow_clone]]shallow clone::
> + A clone of a <> which creates a
> + <>.
> +
> 
> I read this sentence, especially the part "A clone ... which creates"
> as referring to "an act of running the 'git clone' command", not
> "the (shallow) repository that results from such an act", and found
> it a bit strange.
> 
> Right now, I do not think we have a canned way to create a shallow
> repository locally without running "git clone --depth", but there is
> no fundamental reason you shouldn't be able to do so (we can even
> today create a shallow repository manually using lower-level tools
> without running "clone --depth" from elsewhere).  And for somebody
> who has seen such a repository, "a shallow clone" and "a shallow
> repository" would have a slight difference.  The former is a shallow
> repository that was created using "clone --depth"; the latter may or
> may not ahve been created with "clone --depth", it just says the
> repository does not have full history without hinting how it was
> made so.
> 
> Perhaps replace 1/2 with something like this?
> 
> [[def_shallow_clone]]shallow clone::
> Mostly a synonym to <>
> but the phrase makes it more explicit that it was created by
> running `git clone --depth=...` command.
> 
> [[def_shallow_repository]]shallow repository::
> A shallow <> has an incomplete
> history some of whose <> have
> <> cauter
> 
That seems like better wording.

Until I started working on this I wasn't really aware of the term shallow 
repository.   
Everything I had seen was

Re: [PATCH] user-manual: remove temporary branch entry from todo list

2015-12-27 Thread Stephen &amp; Linda Smith 
On Sunday, December 27, 2015 06:41:09 PM Junio C Hamano wrote:
> "Stephen P. Smith"  writes:
> 
> > Remove the suggestion for using a detached HEAD instead of a
> > temporary branch.
> 
> That is something we can read from the patch text.  Please explain
> why it is a good idea to remove it.
> 
> I can think of two completely different reasons:
> 
>  (1) Maybe the task was done some time ago, and we are seeing a
>  stale todo item?
> 
>  (2) The task the todo item hints at was not done, but maybe it is
>  not a good thing to do after all?
> 
> You seem to be hinting the former, but I do not think "the task was
> done" is the case here.
 
I think that this is a stale todo.   
 
The only place there is a mention of temporary branches (which 
is then parenthetically called a topic branch) is in relation to how Tony Luck 
organizes his work.   
Additionally there is already a subsection on using a detatched head 
("Examining an 
old version without creating a new branch). 
 
If there is more that was wanted, then I would be glad to add something, but 
I don't see that there are references to remove.
 
> 
> > Signed-off-by: Stephen P. Smith 
> > ---
> >
> > Notes:
> > A search of the user manual found only one location which refers to
> > temporary branches.  This has to do with how Tony Luck uses them.
> > 
> > Even then there is a clarifying parenthetical noting that the
> > temporary branches are topic branches.
> > 
> > A git blame showed that the last time that the entry was updated was
> > in 2007.
> >
> >  Documentation/user-manual.txt | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index 1c790ac..18e2f1e 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -4636,9 +4636,6 @@ Scan email archives for other stuff left out
> >  Scan man pages to see if any assume more background than this manual
> >  provides.
> >  
> > -Simplify beginning by suggesting disconnected head instead of
> > -temporary branch creation?
> > -
> 
> What does "beginning" refer to in this sentence, though?

I had that question too even after looking at the 2007 version of the manual.

> 
> After a quick reading of the beginning part of the document, I am
> getting the impression that it refers to the use of the 'new'
> branch, which is initially created out of v2.6.13 and then later
> reset to v2.6.17 while the user is in the sightseeing mode.  And
> this way of working _is_ a remnant from the days back when detached
> HEAD was not with us.
> 
> It is a completely separate matter if it is a good idea to teach
> detached HEAD that early in the tutorial, though.  
 
So are you suggesting a move of the section further down?   
Or are you suggesting that that is excised from the manual?

> So "remove the task because detached HEAD is a bit too weird thing to learn 
> in that
> early stage in the learning curve" (i.e. the latter reason) might
> apply.
 
Could it be there are two reasons to remove the todo?

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

--
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: [PATCH V2 x/2] user-manual: add section documenting shallow clones

2015-12-22 Thread Stephen &amp; Linda Smith 
I just realized that the two patches I sent earlier were missing the Signed by 
lines.   I will be resending them.

sps
--
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: [PATCH 2/2] Add a section to the users manual documenting shallow clones.

2015-12-22 Thread Stephen &amp; Linda Smith 
On Monday, December 21, 2015 10:47:16 PM Eric Sunshine wrote:
> On Mon, Dec 21, 2015 at 9:09 PM, Stephen P. Smith  wrote:
> >  [[repositories-and-branches]]
> >  Repositories and Branches
> >  =
> > @@ -72,6 +71,25 @@ called the <>, together 
> > with a special
> >  top-level directory named `.git`, which contains all the information
> >  about the history of the project.
> >
> > +[[how-to-get-a-git-repository-with-minimal-history]]
> > +How to get a Git repository with minimal history
> > +
> 
> Is this a good placement for this topic? Shallow repositories are not
> heavily used, yet this placement amidst the very early and important
> topics of cloning and checking out branches assigns potentially
> significant (and perhaps unwarranted) weight to something used so
> rarely.

After some thought I think that the section should be moved near the bottom of 
"Sharing development with others" since 1) that would reduce the significance 
and 2) it seems that a shallow clone would normally be used for contributing to 
a 
large project when downloading the entire history is expensive.
Should it be placed just above the Tony Luk example?

sps
--
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: Someplace to contribute: documentation

2015-12-21 Thread Stephen &amp; Linda Smith 
On Sunday, December 20, 2015 06:27:56 PM Stephen & Linda Smith wrote:
> I've been looking over the git source tree to see if there is some place 
> where I can 
> contribute.   It appears that there are some suggestions at the bottom of 
> the userguide.  Does anyone have other places that they would like 
> worked on first?  If not I will start with one of the suggestions.

I am looking at the documentation for shallow clones and it apears either that 
the name  has changed over time to shallow repositories or there needs 
to be a glossary entry and some cross references. Are they two separate 
things?   If not, what is the sematic difference?



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

Someplace to contribute: documentation

2015-12-20 Thread Stephen &amp; Linda Smith 
I've been looking over the git source tree to see if there is some place where 
I can 
contribute.   It appears that there are some suggestions at the bottom of 
the userguide.  Does anyone have other places that they would like 
worked on first?  If not I will start with one of the suggestions.
 
sps
--
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

Signed tags and git repository

2015-11-25 Thread Stephen &amp; Linda Smith 
I've been following commits to the linux and git repostitories for some time.   
I used signed tags for
projects that I'm working on.   

I know that the linux and git repositories have signed tags, but I'm not able 
to verify 
them because my key isn't signed by anyone that leads back to one of the git or 
linux 
maintainers. Of course I live in a technical desert since there seems to be no 
one that I
can find who lives in Phoenix, AZ that has a relationship to one of those two 
git repositories.

What have others done when they want their keys signed so they can be part of 
the 
web of trust? Does either of those two projects have a formal way of 
establishing these
relationships?

sps
--
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: Signed tags and git repository

2015-11-25 Thread Stephen &amp; Linda Smith 
On Thursday, November 26, 2015 04:56:00 AM Johannes Löthberg wrote:

> You don't even need the Web of Trust though, you can just verify the 
> signature and then check that the key used to make the signature is the 
> correct one, 

Ok, but if I don't have a link to the Web or Trust, how do I know that "the
key used to make sure the signature is the correct one" (i.e. trusted).

sps


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] How to keep a project's canonical history correct.

2014-05-09 Thread Stephen Linda Smith 
On Friday, May 09, 2014 02:05:44 PM Junio C Hamano wrote:
 I needed a few tweaks on top while queuing.  You will find the
 result on 'pu' after I push it out.
 
 In addition to one typofix (because lacking c), here are what I
 did:
 
  - Typeset concrete command e.g. `git pull` in monospace.
 
  - The second and subsequent paragraphs continued with + need to
be flushed to the left; leaving them indented will format them in
monospace (see with `git pull --rebase` or something).
 
  - Be more explicit in describing 'trunk' being 'the first-parent
chain' in the text.
 
  - Refer to a newer article that discusses this exact topic.
 
  - De-emphasize 'fix-bug-12345' in Merge fix-bug-12345 log message.
 
  - Describe what the final history illustration shows.
 
 
 Unless you have objections to the below (or suggestions for better
 alternatives), there is no need to resend the patch.
 

I like the changes.


--
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: Beginner question on Pull is mostly evil

2014-05-07 Thread Stephen Linda Smith 
I'll create a patch.

On Wednesday, May 07, 2014 01:51:04 PM Junio C Hamano wrote:
 Jim Garrison jim.garri...@nwea.org writes:
 
  -Original Message-
  From: Junio C Hamano
  Sent: Wednesday, May 07, 2014 1:16 PM
  Subject: Re: Beginner question on Pull is mostly evil
  
  No.  This is most often true for people who use a single repository as a
  place for everybody to meet, in the same way as SVN.
  [snip lots of excellent detail]
  HTH.
 
  Wow.  That helps tremendously, and should be incorporated somewhere in the
  Git documentation.  Thank you for your immensely detailed response.
 
 We used to collect useful list postings in Documentation/howto/;
 perhaps somebody wants to do the minimum copyediting of the message
 and send a patch?
 --
 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

--
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: merging commit history

2013-07-16 Thread Stephen Linda Smith 
I did as Andrew suggested and created two git repositories  with one  branch 
using oldCM history and the second branch using having the svn history.  

Then I checked out the svn branch and rebased onto oldCM.   The head of the 
combined branch is named master.

How do I manually set git/git-svn up so that HEAD  points to -r rev  in the svn 
repository?Googling doesn't come up with a solution; I previously thought 
google knows all.

When done, I would like git svn dcommit to be able to commit to the svn repo.

Thanks
sps

On Friday, July 12, 2013 10:11:41 AM Andrew Ardill wrote:
 On 12 July 2013 09:43, Stephen  Linda Smith isch...@cox.net wrote:
  I'm working on a project that used to use a proprietary CM system (aka 
  oldCM).   At a point in time, the state of the code was frozen and used as 
  the basis for commits in SVN.
 
  What I would like to to do is take the individal commits from the oldCM and 
  place them into git knowing that the time/date stamps won't match.  Then I 
  want to do whatever is necessary to
  setup git so that I can run svn rebase to pull in the commits from the 
  SVN repository.
 
  What is the easy way to do this?
 
 
 There may be other tools that make this easier, but if I had this
 problem I would simply create two repositories, one for oldCM and one
 for SVN. I would then merge the two together (as branches with
 different roots) and do my rebase from there.
 
 I haven't tried this, and maybe there is something I am missing, but
 there shouldn't be too much pain going that way.
 
 
 Regards,
 
 Andrew Ardill
 --
 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
--
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

merging commit history

2013-07-11 Thread Stephen Linda Smith 
I'm working on a project that used to use a proprietary CM system (aka oldCM).  
 At a point in time, the state of the code was frozen and used as the basis for 
commits in SVN.

What I would like to to do is take the individal commits from the oldCM and 
place them into git knowing that the time/date stamps won't match.  Then I want 
to do whatever is necessary to
setup git so that I can run svn rebase to pull in the commits from the SVN 
repository.

What is the easy way to do this?
--
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: Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-06 Thread Stephen Linda Smith 
On Sunday, January 06, 2013 04:09:17 AM Jonathan Nieder wrote:
 Mark Levedahl wrote:
   However, the
   newer
  
  win32api is provided only for the current cygwin release series, which can
  be reliably identified by having dll version 1.7.x, while the older frozen
  releases (dll versions 1.6.x from redhat, 1.5.x open source) still have
  the
  older api as no updates are being made for the legacy version(s).
 
 Ah.  That makes sense, thanks.
 
 (For the future, if we wanted to diagnose an out-of-date win32api and
 print a helpful message, I guess cygcheck would be the command to use.)

Thank you for the information.   I will update my cygwin installation.
--
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

Version 1.8.1 does not compile on Cygwin 1.7.14

2013-01-05 Thread Stephen Linda Smith 
 Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message states that
 the macro was being renamed for clarity. The patch also changes a define.

This change causes the code to not compile on cygwin 1.7.14.

 I narrowed the problem to this patch by bisecting commits between v1.8.0 and 
1.8.1

Here is the error sequence:

CC compat/cygwin.o
In file included from compat/../git-compat-util.h:90,
 from compat/cygwin.c:9:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
warning: #warning fd_set and associated macros have been defined in sys/types. 
 
This may cause runtime problems with W32 sockets
In file included from /usr/include/sys/socket.h:16,
 from compat/../git-compat-util.h:131,
 from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr'
/usr/include/cygwin/socket.h:41: error: redefinition of `struct 
sockaddr_storage'
In file included from /usr/include/sys/socket.h:16,
 from compat/../git-compat-util.h:131,
 from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:59: error: redefinition of `struct linger'
In file included from compat/../git-compat-util.h:131,
 from compat/cygwin.c:9:
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: 
error: previous declaration of 'accept' was here
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: 
error: previous declaration of 'accept' was here
/usr/include/sys/socket.h:32: error: conflicting types for 'bind'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537: 
error: previous declaration of 'bind' was here
/usr/include/sys/socket.h:32: error: conflicting types for 'bind'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:537: 
error: previous declaration of 'bind' was here
/usr/include/sys/socket.h:33: error: conflicting types for 'connect'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539: 
error: previous declaration of 'connect' was here
/usr/include/sys/socket.h:33: error: conflicting types for 'connect'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:539: 
error: previous declaration of 'connect' was here
/usr/include/sys/socket.h:34: error: conflicting types for 'getpeername'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541: 
error: previous declaration of 'getpeername' was here
/usr/include/sys/socket.h:34: error: conflicting types for 'getpeername'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:541: 
error: previous declaration of 'getpeername' was here
/usr/include/sys/socket.h:35: error: conflicting types for 'getsockname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542: 
error: previous declaration of 'getsockname' was here
/usr/include/sys/socket.h:35: error: conflicting types for 'getsockname'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:542: 
error: previous declaration of 'getsockname' was here
/usr/include/sys/socket.h:36: error: conflicting types for 'listen'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546: 
error: previous declaration of 'listen' was here
/usr/include/sys/socket.h:36: error: conflicting types for 'listen'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:546: 
error: previous declaration of 'listen' was here
/usr/include/sys/socket.h:37: error: conflicting types for 'recv'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547: 
error: previous declaration of 'recv' was here
/usr/include/sys/socket.h:37: error: conflicting types for 'recv'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:547: 
error: previous declaration of 'recv' was here
/usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548: 
error: previous declaration of 'recvfrom' was here
/usr/include/sys/socket.h:39: error: conflicting types for 'recvfrom'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:548: 
error: previous declaration of 'recvfrom' was here
/usr/include/sys/socket.h:41: error: conflicting types for 'send'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549: 
error: previous declaration of 'send' was here
/usr/include/sys/socket.h:41: error: conflicting types for 'send'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:549: 
error: previous declaration of 'send' was here
/usr/include/sys/socket.h:44: error: conflicting types for 'sendto'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:550: 
error: previous declaration of