www.tombraiderforums.com

Go Back   www.tombraiderforums.com > Tomb Raider Modding > Tomb Raider Level Editor > Software Development

Reply
 
Thread Tools
Old 23-06-16, 17:11   #2001
stohrendorf
Hobbyist
 
stohrendorf's Avatar
 
Join Date: Jul 2015
Location: Aachen, Germany
Posts: 77
Default

git pull --rebase
stohrendorf is offline   Reply With Quote
Old 23-06-16, 17:17   #2002
vvsgh
Student
 
Join Date: Jun 2015
Posts: 124
Default

Quote:
Originally Posted by Nickotte View Post
Could you please elaborate as to what this means?
Ok, that's how I do it. I have a separate local branch where all my private modifications are stored. Every time master branch changes I rebase that local branch on it. Now I can reset my local master to origin without changing the workspace. Any changes will remain unstaged and should be added explicitly. After that it can be pushed to published branch. All my local changes are still kept in the local branch in my repository.
vvsgh is offline   Reply With Quote
Old 23-06-16, 17:32   #2003
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 194
Default

git pull --rebase or git pull origin branch_name, resolve conflicts, git add -u, git commit...
TeslaRus is offline   Reply With Quote
Old 23-06-16, 17:58   #2004
Gh0stBlade
Archaeologist
 
Gh0stBlade's Avatar
 
Join Date: Dec 2010
Posts: 1,899
Default

Ok so, if anyone wants to join the OpenTomb slack team you can do so by going here. It should be possible to request access if you have a Slack account.

We currently have channels for:

1. Developers.
2. QA (Testers).
3. Public (Anyone just following the project).

Feel free to join
Gh0stBlade is offline   Reply With Quote
Old 23-06-16, 18:27   #2005
Nickotte
Historian
 
Nickotte's Avatar
 
Join Date: May 2010
Location: Italy
Posts: 257
Default

Quote:
Originally Posted by vvsgh View Post
Now I can reset my local master to origin without changing the workspace. Any changes will remain unstaged and should be added explicitly. After that it can be pushed to published branch. All my local changes are still kept in the local branch in my repository.
Sorry, but I still don't quite understand
If I get it correctly, I can update my working branch easily with "rebase", but what about when I have to submit a feature? I would need to strip the branch of all the unnecessary conflicts.
Nickotte is offline   Reply With Quote
Old 23-06-16, 18:42   #2006
vvsgh
Student
 
Join Date: Jun 2015
Posts: 124
Default

Quote:
Originally Posted by Nickotte View Post
but what about when I have to submit a feature? I would need to strip the branch of all the unnecessary conflicts.
My workflow work best when I want to make a small fix. If you want to work on a feature then you still can do it in a separate branch. All you need is that private changes should remain unstaged and kept in a separate branch. That works well if you have a different project files and some small patches which do not conflict with your feature, i.e. it works great with .gitignore or C::B project.

You can look at example in `git help reset` under `interrupted workflow`.

Last edited by vvsgh; 23-06-16 at 19:35.
vvsgh is offline   Reply With Quote
Old 23-06-16, 19:27   #2007
Nickotte
Historian
 
Nickotte's Avatar
 
Join Date: May 2010
Location: Italy
Posts: 257
Default

Welp... it's probably bad practice, but I decided to just use a symlink and have a separate folder for my personal C::B project files. XD
Now, if I ever need to submit a PR or update the source, git is gonna acknowledge the modified code but not the C::B files, so no commit is gonna overwrite the original project, yet I retain a customized workspace
Nickotte is offline   Reply With Quote
Old 23-06-16, 19:39   #2008
stltomb
Hobbyist
 
stltomb's Avatar
 
Join Date: Jul 2015
Posts: 1
Default

Quote:
Originally Posted by Nickotte View Post
Does anyone know what's the proper manner to change settings in the C::B project or other tracked files other than source, that wouldn't mess everything up for everyone else in case of a pull request?
If all you need is to ignore some files without changing the .gitignore file, there is also a local per-repository .gitignore file that you can modify without affecting anyone else: .git/info/exclude

It has exactly the same syntax as a standard .gitignore file.

EDIT: this works for untracked files only, a sparse checkout can be used for tracked files

Last edited by stltomb; 23-06-16 at 22:36. Reason: clarification
stltomb is offline   Reply With Quote
Old 23-06-16, 20:00   #2009
Nickotte
Historian
 
Nickotte's Avatar
 
Join Date: May 2010
Location: Italy
Posts: 257
Default

Quote:
Originally Posted by stltomb View Post
If all you need is to ignore some files without changing the .gitignore file, there is also a local per-repository .gitignore file that you can modify without affecting anyone else: .git/info/exclude

It has exactly the same syntax as a standard .gitignore file.
Oh, sweet!
Nickotte is offline   Reply With Quote
Old 24-06-16, 09:08   #2010
TeslaRus
Student
 
TeslaRus's Avatar
 
Join Date: Jan 2013
Posts: 194
Default

This time I can't push readme to github (do it later ~7 hours);
For merge requests:
* Special merge request, not for merging or with delayed time for merging must contains in name `[NOT_FOR_MERGING]` prefix; that requests may be merged only after request's autor writes comment `[CAN_BE_MERGED_NOW]`;

I know how to fix last physics bug (see TODO, climbing), so I will fix it today;
TeslaRus is offline   Reply With Quote
Reply

Bookmarks

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT. The time now is 20:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.