Ticket #1780 (closed defect: fixed)
Remove own declaration of errno
Reported by: | metux | Owned by: | metux |
---|---|---|---|
Priority: | major | Milestone: | 4.7.1 |
Component: | mc-core | Version: | 4.7.0-pre4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Branch state: | Votes for changeset: | committed-master |
Description (last modified by metux) (diff)
branch: 1780_remove_errno_decl
changeset:1780_remove_errno_decl
Change History
comment:1 Changed 15 years ago by metux
- Owner set to metux
- Status changed from new to accepted
- Description modified (diff)
- severity changed from no branch to on review
comment:2 Changed 15 years ago by slavazanko
Added commits:
- 4b730c24a0f41b2178e1c5d02d64f220d2f35714: Removing calls of strerror() function in mc-core
- b94fb331c3860004119179a289945ea774cb6db9: Removed calls to strerror() function from own libsamba implementation.
Please remember: own libsamba will dropped in near time (we will use libsmbclient instead)
Therefore no need to much changes in own deprecated code.
comment:4 Changed 15 years ago by metux
rebased to current master, running through testfarm
please review
comment:9 follow-up: ↓ 10 Changed 15 years ago by slavazanko
No need to often rebase.
- b3e5c4ca3262e5588a04e49309919483a2dac88c: removing own declaration of errno and strerror()
- 49f5893c15e12465940ca3ed16b75570bbdb6b64: Removing calls of strerror() function in mc-core
- 7393892f2a4037969b7baddfdc4816927f69320f: Removed calls to strerror() function from own libsamba implementation.
I'm made last patch, therefore review please.
comment:10 in reply to: ↑ 9 Changed 15 years ago by metux
- Votes for changeset set to metux
- Description modified (diff)
Replying to slavazanko:
No need to often rebase.
I'm rebasing all my branches when the origin (in this
case master) is updated. the rule is: keep as close
as possible. This prevents later merge conflicts.
As master changed, and there _WAS_ an conflict, i rebased again.
I'm now voting for your commits, you could do it for mine,
(count them together as one) and then wait for another one ...
comment:11 follow-up: ↓ 13 Changed 15 years ago by slavazanko
I'm rebasing all my branches when the origin (in this
case master) is updated. the rule is: keep as close
as possible. This prevents later merge conflicts.
Just try:
git checkout master git merge origin/your_branch # see if any conflicts present this stage git reset --hard origin/master
This operation checks if your branch will conflict with master. In this case (and only in this case) you may rebase branch. You may do this check in dedicated script... :)
I'm now voting for your commits, you could do it for mine
In this branch? No, I can't vote. I'm owner of last patch, therefore others will vite for this patch, not I. We always vote to last patch.
and then wait for another one ...
yep, now we wait for another one vote.
comment:13 in reply to: ↑ 11 Changed 15 years ago by metux
Replying to slavazanko:
I'm rebasing all my branches when the origin (in this
case master) is updated. the rule is: keep as close
as possible. This prevents later merge conflicts.
Just try:
git checkout master git merge origin/your_branch # see if any conflicts present this stage git reset --hard origin/master
Well, I'm doing contigious integration workflow (running through testfarm once something's changed) to catch errors as soon as possible. So contigious rebasing absolutely makes sense, IMHO.
comment:14 Changed 15 years ago by metux
Please review.
comment:15 Changed 15 years ago by andrew_b
- Votes for changeset changed from metux to metux andrew_b
- severity changed from on review to approved
- Blocked By 1872 removed
- Milestone changed from 4.7 to 4.7.1
comment:16 Changed 15 years ago by metux
- Status changed from accepted to testing
- Resolution set to fixed
- severity changed from approved to merged
comment:17 Changed 15 years ago by andrew_b
- Status changed from testing to closed
- Votes for changeset changed from metux andrew_b to commited-master
git log --pretty=oneline e5fdb34..09e2003