Development using git:Developer repositories - Revision history

Sertonix: update link to not be dead

2023-08-25T11:07:35Z

update link to not be dead

← Older revision		Revision as of 11:07, 25 August 2023
Line 7:		Line 7:

	== Git Push (Distributed Workflows) ==		== Git Push (Distributed Workflows) ==
	When working with [https://~~book.~~git-scm.com/~~3_distributed_workflows.html~~ Distributed Workflows]~~{{dead link}}~~ you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.		When working with [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.

	To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).		To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).

Zcrayfish: /* Git Push (Distributed Workflows) */ Marked a dead link.

2023-08-25T03:25:52Z

Git Push (Distributed Workflows): Marked a dead link.

← Older revision		Revision as of 03:25, 25 August 2023
Line 7:		Line 7:

	== Git Push (Distributed Workflows) ==		== Git Push (Distributed Workflows) ==
	When working with [https://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.		When working with [https://book.git-scm.com/3_distributed_workflows.html Distributed Workflows]{{dead link}} you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.

	To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).		To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).

Sertonix: ignore git links

2023-08-07T10:48:32Z

ignore git links

← Older revision		Revision as of 10:48, 7 August 2023
Line 11:		Line 11:
	To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).		To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).
	{{cmd\|cd /your/private/repo/where/you/work/reponame		{{cmd\|cd /your/private/repo/where/you/work/reponame
	git config remote.origin.pushurl "ssh://user@dev.alpinelinux.org/home/user/cgit/reponame.git"}}		git config remote.origin.pushurl "<nowiki>ssh://user@dev.alpinelinux.org/home/user/cgit/reponame.git</nowiki>"}}
	Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.		Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.
	{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}		{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}
Line 26:		Line 26:
	If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.		If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.

	You can ask directly on IRC #alpine-devel or by sending an email to alpine-devel mailing list. Please include the git url (eg. git://git.alpinelinux.org/user/aports.git) that can easily be copied and pasted and please also mention ''why'' the merge is needed. This explanation is meant to be copied and pasted in the merge commit unless the pull is a fast-forward.		You can ask directly on IRC #alpine-devel or by sending an email to alpine-devel mailing list. Please include the git url (eg. <nowiki>git://git.alpinelinux.org/user/aports.git</nowiki>) that can easily be copied and pasted and please also mention ''why'' the merge is needed. This explanation is meant to be copied and pasted in the merge commit unless the pull is a fast-forward.

	Example request on IRC:		Example request on IRC:

Sertonix: use https

2023-08-07T10:46:42Z

use https

Fab: Add tld

2016-11-06T14:02:38Z

Add tld

← Older revision		Revision as of 14:02, 6 November 2016
Line 11:		Line 11:
	To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).		To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).
	{{cmd\|cd /your/private/repo/where/you/work/reponame		{{cmd\|cd /your/private/repo/where/you/work/reponame
	git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}		git config remote.origin.pushurl "ssh://user@dev.alpinelinux.org/home/user/cgit/reponame.git"}}
	Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.		Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.
	{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}		{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}

Ncopa: place TOC at the top

2012-07-09T07:20:16Z

place TOC at the top

← Older revision		Revision as of 07:20, 9 July 2012
Line 1:		Line 1:
			__TOC__
	__FORCETOC__		__FORCETOC__

Ncopa: force table of contents

2012-07-09T07:19:32Z

force table of contents

← Older revision		Revision as of 07:19, 9 July 2012
Line 1:		Line 1:
			__FORCETOC__

	Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.		Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.

Ncopa: /* Requesting a pull from developer repo to official */ fix examples to be more copy paste friendly

2012-05-18T09:47:01Z

Requesting a pull from developer repo to official: fix examples to be more copy paste friendly

← Older revision		Revision as of 09:47, 18 May 2012
Line 23:		Line 23:
	If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.		If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.

	You can ask directly on IRC #alpine-devel or by sending an email to alpine-devel mailing list. Please include the git url (eg. git://git.alpinelinux.org/user/aports.git) that can easily be copied and pasted and please also mention ''why'' the merge is needed. This explanation is meant to be copied and pasted in the merge commit.		You can ask directly on IRC #alpine-devel or by sending an email to alpine-devel mailing list. Please include the git url (eg. git://git.alpinelinux.org/user/aports.git) that can easily be copied and pasted and please also mention ''why'' the merge is needed. This explanation is meant to be copied and pasted in the merge commit unless the pull is a fast-forward.

	Example request on IRC:		Example request on IRC:
	<pre>		<pre>
	please pull git://git.alpinelinux.org/ncopa/aports		please git pull git://git.alpinelinux.org/ncopa/aports
	It includes a new python application pyfoo with all its dependencies.		It includes a new python application pyfoo with all its dependencies.
	</pre>		</pre>
Line 33:		Line 33:
	Example email:		Example email:
	<pre>		<pre>
	Subject: please pull git://git.alpinelinux.org/ncopa/aports		Subject: please git pull git://git.alpinelinux.org/ncopa/aports

	The libfoo was upgraded to 2.0. This upgrade breaks ABI so all packages linking		The libfoo was upgraded to 2.0. This upgrade breaks ABI so all packages linking

Ncopa: add how to deal with pull rejects

2012-05-16T20:24:38Z

add how to deal with pull rejects

← Older revision		Revision as of 20:24, 16 May 2012
Line 42:		Line 42:

	</pre>		</pre>

			== Dealing with pull rejects ==
			If the pull was rejected for some reason or you need change things, then you can do an interactive reabase.
			{{Cmd\|git rebase --interactive}}
			This will let you go thru all you commits inteactively, fix up commits and/or commit messages (aka --ammend), merge commits etc. It might be the ''integration manager'' will see what you are trying to fix and just fix it there and then. In that case you might need drop your own commit. This can also be done with ''git rebase''.

			When the needed changes have been done you again push to your public developer repo (and as always you ''git pull --rebase'' before pushing), but since the history have changed due to the rebase git might give you an error message when pushing. As long no-one else have cloned/pulled your repo, it should safe to use --force option.
			{{Cmd\|git push --force}}
			Note that this will overwrite the changes and history on your public repo so make sure that your local work clone has all the commits that should be there. (use git log to verify).

			This also means that only the ''integration managers'' should pull from the developers repo. All other developers should pull from the blessed repository. (In theory multiple developers can work on a bigger subproject but then one of the developers should work as a ''lieutenant'' in the [http://git-scm.com/book/ch5-1.html#Dictator-and-Lieutenants-Workflow dictator and lieutenants workflow].)

	[[Category:Development]]		[[Category:Development]]
	[[Category:Git]]		[[Category:Git]]

Ncopa: reword a little to make text fit more with the distributed workflow diagrams

2012-05-16T20:07:31Z

reword a little to make text fit more with the distributed workflow diagrams

← Older revision		Revision as of 10:46, 7 August 2023
Line 2:		Line 2:
	__FORCETOC__		__FORCETOC__

	Some git repositories of Alpine developer are hosted at [~~http~~://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.		Some git repositories of Alpine developer are hosted at [https://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.

	The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.		The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.

	== Git Push (Distributed Workflows) ==		== Git Push (Distributed Workflows) ==
	When working with [~~http~~://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.		When working with [https://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.

	To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).		To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).
Line 18:		Line 18:
	Before asking for merging the developer repo into the official make sure that:		Before asking for merging the developer repo into the official make sure that:
	# All modified packages builds		# All modified packages builds
	# The commit history looks nice. You can use the [~~http~~://git.alpinelinux.org~~/cgit~~ cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future so avoid changing multiple packages with single commits.		# The commit history looks nice. You can use the [https://git.alpinelinux.org cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future so avoid changing multiple packages with single commits.

	Before asking for a pull, rebase your public repo with the official repo. This is done with:		Before asking for a pull, rebase your public repo with the official repo. This is done with:
Line 55:		Line 55:
	Note that this will overwrite the changes and history on your public repo so make sure that your local work clone has all the commits that should be there. (use git log to verify).		Note that this will overwrite the changes and history on your public repo so make sure that your local work clone has all the commits that should be there. (use git log to verify).

	This also means that only the ''integration managers'' should pull from the developers repo. All other developers should pull from the blessed repository. (In theory multiple developers can work on a bigger subproject but then one of the developers should work as a ''lieutenant'' in the [~~http~~://git-scm.com/book/ch5-1.html#Dictator-and-Lieutenants-Workflow dictator and lieutenants workflow].)		This also means that only the ''integration managers'' should pull from the developers repo. All other developers should pull from the blessed repository. (In theory multiple developers can work on a bigger subproject but then one of the developers should work as a ''lieutenant'' in the [https://git-scm.com/book/ch5-1.html#Dictator-and-Lieutenants-Workflow dictator and lieutenants workflow].)

	[[Category:Development]]		[[Category:Development]]
	[[Category:Git]]		[[Category:Git]]

← Older revision		Revision as of 20:07, 16 May 2012
Line 1:		Line 1:
	Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access can review and pull from this or can choose to reject if the changes needs more fixing.		Some git repositories of Alpine developer are hosted at [http://git.alpinelinux.org/ git.alpinelinux.org]. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, ''integration managers'', can review and pull from this or can choose to reject if the changes needs more fixing.

	The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.		The git repos are to be used when there are many changes (more than 3) that need no or very little review. If comments are requested or if there are doubts, then its better to use ''git send-email''. It might also be better to use ''git send-email'' for single commits.

	== Git Push (Distributed Workflows) ==		== Git Push (Distributed Workflows) ==
	If working with [http://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main ~~developer~~ ''(who ~~has~~ write access to public repository~~)''~~ 'pulls' you changes from your ~~publically~~ accessed repository into the public repository.		When working with [http://book.git-scm.com/3_distributed_workflows.html Distributed Workflows] you would 'pull' from public repository, 'push' to another publically accessible repository ''(where you have write access)'', main developeres or ''integration managers'' who have write access to public repository, 'pulls' you changes from your public accessed repository into the blessed official public repository.

	To make it easier for you to work, you can configure 'git push' to push your work to your ~~publically accessible~~ repository ''('git pull' would still pull from ~~same~~ repository as you cloned from)''.		To make it easier for you to work, you can configure 'git push' to push your work to your public developer repository ('git pull' would still pull from the blessed/official repository as you cloned from).
	{{cmd\|cd /your/private/repo/where/you/work/reponame		{{cmd\|cd /your/private/repo/where/you/work/reponame
	git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}		git config remote.origin.pushurl "ssh://user@dev.alpinelinux/home/user/cgit/reponame.git"}}
	Now 'git pull' pulls the ~~public~~ repository and 'git push' pushes to '''your''' public repository.		Now 'git pull' pulls the official, blessed, repository and 'git push' pushes to '''your''' public developer repository.
	{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}		{{Note\|The path where you want to push to should first be prepared with {{cmd\|git clone --bare ...}} as described below in section 'Upload the new project'}}

Line 15:		Line 15:
	Before asking for merging the developer repo into the official make sure that:		Before asking for merging the developer repo into the official make sure that:
	# All modified packages builds		# All modified packages builds
	# The commit history looks nice. You can use the [http://git.alpinelinux.org/cgit cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future~~. So~~ avoid changing multiple packages with single commits.		# The commit history looks nice. You can use the [http://git.alpinelinux.org/cgit cgit interface] for this. It is a goal that it should be easy to revert single commits in case problems should appear in future so avoid changing multiple packages with single commits.

	Before asking for a pull, rebase your public repo with the official repo. This is done with:		Before asking for a pull, rebase your public repo with the official repo. This is done with:
	{{Cmd\|git pull --rebase}}		{{Cmd\|git pull --rebase
	~~{{Cmd\|~~git push}}		git push}}

	If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.		If there have been changes in official repo that conflicts with your work, then you have to resolve those conflicts. And maybe redo or drop some of your commits.