Fidonet Echo Reader :: RU.UNIX.BSD

#182761	From:	Alexey Fayans
	To:	Victor Sudakov
	Date:	24-05-2020 04:09:15
	Subj:	git workflow

Hello Victor!

On Sun, 24 May 2020 at 01:10 +0700, you wrote to me:

AF>> Можно просто коммитить в мастер, при каждом git pull будет
AF>> происходить merge, как ты и хочешь.
VS> А почему тогда пишут "в мастер не коммитить"?

Никто тебе не запрещает коммитить в мастер. Это рекомендация. Ориентирована она скорее на тех, кто занимается разработкой. Поэтому если ты будешь коммитить в мастер, твои коммиты в ориджин не пройдут (в большинстве случаев, это общепринятая практика). Обычно делают свою ветку, коммитят туда, потом делают pull request, чтобы изменения из твоей ветки приняли в мастер.

VS> Да и ломалось что-то у
VS> меня от такого, гит писал "you are ahead of master", видимо не зря
VS> предупреждают.

Это не ошибка. В случае git pull просто будет автоматический merge твоих коммитов. Если будет конфликт, нужно будет его руками исправить, и всё.

... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
SEEN-BY: 5020/715 1042 5023/24 5030/1997 6090/1
PATH: 5030/1997 5023/24 5020/715 1042 6090/1

#182762	From:	Victor Sudakov
	To:	eugen
	Date:	24-05-2020 16:08:22
	Subj:	git workflow

Dear eugen,

24 May 20 07:46, Eugene Grosbein wrote to me:

VS>> И как всё-таки лучше, коммитить в мастер и стягивать в него же,
VS>> или стягивать в мастер, а свои изменения делать в своей ветке и
VS>> сливать в неё из мастера? Какие плюсы-минусы у обоих подходов?

EG> Я не знаю, какой там workflow в git и вообще git'ом для разработки
EG> не пользуюсь, но для меня всегда естественным было отделять мух от
EG> котлет: есть "vendor branch", пусть он будет master или отдельная
EG> ветка, не суть важно и мы его не трогаем, а только вливаем в него
EG> изменения из апстрима; а есть наша собственная ветка, которую мы
EG> меняем своими изменениями.

EG> После очередного обновления "vendor branch" ты можешь получить
EG> новый "релиз" со своими патчами, приложив накопленные свои изменения
EG> к новой "базе", но не изменяя собственно "vendor branch".

Я помню этот workflow ещё со времен, когда исходники FreeBSD были в CVS! Только сейчас предлагается не *свои* изменения прикладывать к "новой базе", а наоборот изменения из мастера (который у нас выступает в роли vendor branch) мержить в свою ветку:

git clone ....
git checkout -b mylocal
тут чего-то правим
git commit -a
git checkout master
git pull
git checkout mнlocal
git merge
git commit -a -m "merged recent changes from upstream"

EG> Если они всё ещё прикладываются гладко, то и ладушки,
EG> а если нет - разрешаешь конфликт и, при желании, можешь создать новую
EG> собственную ветку на основе текущего состояния "vendor branch"
EG> и разрешенных конфликтов.

И потом все эти ветки расплодятся и перестанешь понимать, что где.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20170303-b20170303
* Origin: Ulthar (2:5005/49)
SEEN-BY: 5005/49 5020/1042 6090/1
PATH: 5005/49 5020/1042 6090/1

#182763	From:	Eugene Grosbein
	To:	Victor Sudakov
	Date:	25-05-2020 00:11:22
	Subj:	Re: git workflow

24 мая 2020, воскресенье, в 16:08 NOVT, Victor Sudakov написал(а):

VS>>> И как всё-таки лучше, коммитить в мастер и стягивать в него же,
VS>>> или стягивать в мастер, а свои изменения делать в своей ветке и
VS>>> сливать в неё из мастера? Какие плюсы-минусы у обоих подходов?
EG>> Я не знаю, какой там workflow в git и вообще git'ом для разработки
EG>> не пользуюсь, но для меня всегда естественным было отделять мух от
EG>> котлет: есть "vendor branch", пусть он будет master или отдельная
EG>> ветка, не суть важно и мы его не трогаем, а только вливаем в него
EG>> изменения из апстрима; а есть наша собственная ветка, которую мы
EG>> меняем своими изменениями.
EG>> После очередного обновления "vendor branch" ты можешь получить
EG>> новый "релиз" со своими патчами, приложив накопленные свои изменения
EG>> к новой "базе", но не изменяя собственно "vendor branch".
VS> Я помню этот workflow ещё со времен, когда исходники FreeBSD были в CVS! Только
VS> сейчас предлагается не *свои* изменения прикладывать к "новой базе", а наоборот
VS> изменения из мастера (который у нас выступает в роли vendor branch) мержить в
VS> свою ветку:

То есть, смешивать мух с котлетами. Ради чего? Hиоткуда не следует,
что новый апстримовский код смержится с твоей веткой, но он он
точно вольётся в нетронутый vendor branch.

EG>> Если они всё ещё прикладываются гладко, то и ладушки,
EG>> а если нет - разрешаешь конфликт и, при желании, можешь создать новую
EG>> собственную ветку на основе текущего состояния "vendor branch"
EG>> и разрешенных конфликтов.

VS> И потом все эти ветки расплодятся и перестанешь понимать, что где.

Это твои собственные ветки, ты их сам создаёшь и именуешь
и имеешь их историю. Перестать понимать, где что, для твоих
собственных, отделённых от мух веток у тебя минимальные шансы.

А если кто-то не в состоянии разобраться со своими собственными
ветками, то может быть, ему не стоит вообще заниматься этим всем.
Профессий много.

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 5006/1 5020/545 1042 4441 5080/102 6090/1
PATH: 5006/1 5080/102 5020/545 4441 1042 6090/1

#182764	From:	Eugene Grosbein
	To:	Victor Sudakov
	Date:	25-05-2020 02:26:02
	Subj:	Re: git workflow

24 мая 2020, воскресенье, в 16:08 NOVT, Victor Sudakov написал(а):

EG>> Если они всё ещё прикладываются гладко, то и ладушки,
EG>> а если нет - разрешаешь конфликт и, при желании, можешь создать новую
EG>> собственную ветку на основе текущего состояния "vendor branch"
EG>> и разрешенных конфликтов.

VS> И потом все эти ветки расплодятся и перестанешь понимать, что где.

Hовую ветку создавать и необязательно, можно просто прокоммитить
разрешенный конфликт с соответствующим log message.
Hе хочешь плодить ветки - не плоди.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 5006/1 5020/545 1042 4441 5080/102 6090/1
PATH: 5006/1 5080/102 5020/545 4441 1042 6090/1

#182765	From:	Alex Korchmar
	To:	Eugene Grosbein
	Date:	25-05-2020 16:52:05
	Subj:	Re: git workflow

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> не пользуюсь, но для меня всегда естественным было отделять мух от котлет:
EG> есть "vendor branch"
в гите это remote/master - он никуда не денется и так, и он нам нах не нужен.

EG> После очередного обновления "vendor branch" ты можешь получить
EG> новый "релиз" со своими патчами, приложив накопленные свои изменения
EG> к новой "базе", но не изменяя собственно "vendor branch".
это если я собираюсь каждый раз делать мартышкину работу - переделывать патчи
под каждое новое состояние "vendor branch". Hо я не собираюсь, и топикстартер
тоже.
Hам нужна наша история изменений, а не "новый релиз со своими патчами".
К счастью, dvcs, даже такие убогие как git, это как раз и позволяют.

Это _мой_ релиз. С патчами из апстрима - если получилось.

Ровно то же самое что freebsd делает с MFV - никто отдельных веток
для них бережно не хранит - потому что они нахрен никому в проекте freebsd
не нужны.

> Alex

--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)
SEEN-BY: 5020/400 545 1042 4441 6090/1
PATH: 5020/400 545 4441 1042 6090/1

#182766	From:	Eugene Grosbein
	To:	All
	Date:	26-05-2020 07:46:21
	Subj:	UFS

хыхы

Author: chs
Date: Mon May 25 23:47:31 2020
New Revision: 361491
URL: https://svnweb.freebsd.org/changeset/base/361491

Log:
This commit enables a UFS filesystem to do a forcible unmount when
the underlying media fails or becomes inaccessible. For example
when a USB flash memory card hosting a UFS filesystem is unplugged.

The strategy for handling disk I/O errors when soft updates are
enabled is to stop writing to the disk of the affected file system
but continue to accept I/O requests and report that all future
writes by the file system to that disk actually succeed. Then
initiate an asynchronous forced unmount of the affected file system.

There are two cases for disk I/O errors:

- ENXIO, which means that this disk is gone and the lower layers
of the storage stack already guarantee that no future I/O to
this disk will succeed.

- EIO (or most other errors), which means that this particular
I/O request has failed but subsequent I/O requests to this
disk might still succeed.

For ENXIO, we can just clear the error and continue, because we
know that the file system cannot affect the on-disk state after we
see this error. For EIO or other errors, we arrange for the geom_vfs
layer to reject all future I/O requests with ENXIO just like is
done when the geom_vfs is orphaned. In both cases, the file system
code can just clear the error and proceed with the forcible unmount.

This new treatment of I/O errors is needed for writes of any buffer
that is involved in a dependency. Most dependencies are described
by a structure attached to the buffer's b_dep field. But some are
created and processed as a result of the completion of the dependencies
attached to the buffer.

Clearing of some dependencies require a read. For example if there
is a dependency that requires an inode to be written, the disk block
containing that inode must be read, the updated inode copied into
place in that buffer, and the buffer then written back to disk.

Often the needed buffer is already in memory and can be used. But
if it needs to be read from the disk, the read will fail, so we
fabricate a buffer full of zeroes and pretend that the read succeeded.
This zero'ed buffer can be updated and written back to disk.

The only case where a buffer full of zeros causes the code to do
the wrong thing is when reading an inode buffer containing an inode
that still has an inode dependency in memory that will reinitialize
the effective link count (i_effnlink) based on the actual link count
(i_nlink) that we read. To handle this case we now store the i_nlink
value that we wrote in the inode dependency so that it can be
restored into the zero'ed buffer thus keeping the tracking of the
inode link count consistent.

Because applications depend on knowing when an attempt to write
their data to stable storage has failed, the fsync(2) and msync(2)
system calls need to return errors if data fails to be written to
stable storage. So these operations return ENXIO for every call
made on files in a file system where we have otherwise been ignoring
I/O errors.

Coauthered by: mckusick
Reviewed by: kib
Tested by: Peter Holm
Approved by: mckusick (mentor)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D24088

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 5006/1 5020/545 1042 4441 5080/102 6090/1
PATH: 5006/1 5080/102 5020/545 4441 1042 6090/1

#182767	From:	Eugene Subbotin
	To:	Eugene Grosbein
	Date:	26-05-2020 13:44:01
	Subj:	Re: UFS

On 26.05.2020 8:46, Eugene Grosbein wrote:

EG> Sponsored by: Netflix

Красавцы!

--- Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Trustedbird/24.3.0
* Origin: Dewy News (2:5075/128)
SEEN-BY: 5020/715 1042 5075/128 6090/1
PATH: 5075/128 5020/715 1042 6090/1

#182768	From:	Alex Korchmar
	To:	Eugene Grosbein
	Date:	27-05-2020 00:23:07
	Subj:	Re: UFS

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
EG> хыхы
шо, не прошло и пятидесяти лет с изобретения дискеты, как выдирание флэшки
на ходу стало можно?

И даже в panic не падает, или только если повезет?

EG> Coauthered by: mckusick
какие люди на нашем болоте. А в 94м он не мог то же самое сделать?

> Alex
P.S. а точку монтирования точно-точно освобождает, или как всегда?

--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)
SEEN-BY: 5020/400 545 1042 4441 6090/1
PATH: 5020/400 545 4441 1042 6090/1

#182769	From:	Alex Korchmar
	To:	Eugene Subbotin
	Date:	27-05-2020 00:25:07
	Subj:	Re: UFS

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Subbotin <Eugene.Subbotin@f128.n5075.z2.fidonet.org> wrote:

EG>> Sponsored by: Netflix
ES> Красавцы!
видимо, их таки зае...ло превращение системы в невосстанавливаемую тыкву.

А про "тут так принято!" и "отцы г-но жрали, деды г-но жрали..." они,
как обычно, не слышали.

Эх, кто бы им zfs как-нибудь хитро подсунул...

> Alex

--- ifmail v.2.15dev5.4
* Origin: Demos online service (2:5020/400)
SEEN-BY: 5020/400 545 1042 4441 6090/1
PATH: 5020/400 545 4441 1042 6090/1

#182770	From:	Eugene Grosbein
	To:	Alex Korchmar
	Date:	27-05-2020 15:07:23
	Subj:	Re: UFS

27 мая 2020, среда, в 00:23 NOVT, Alex Korchmar написал(а):

AK> P.S. а точку монтирования точно-точно освобождает, или как всегда?

Это всё пока только в head, я не пробовал за неимением head,
но если это полноценный umount, хоть и forced, то должно.

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)
SEEN-BY: 5006/1 5020/545 1042 4441 5080/102 6090/1
PATH: 5006/1 5080/102 5020/545 4441 1042 6090/1