The Git/GitHub Questions, Answers and Howto Thread

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderators: Committer, Committer

Message
Author
User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#136 Post by MatGB » Mon Apr 04, 2016 1:33 am

Finally remembered to try this, sorry:

Code: Select all

matgb@MatGB-Desktop:~/freeorion$ ls -al .git/refs/remotes/morlic/AI-Chokepoints
ls: cannot access .git/refs/remotes/morlic/AI-Chokepoints: Permission denied
matgb@MatGB-Desktop:~/freeorion$ ls -al .git/refs/remotes/morlic/
ls: cannot access .git/refs/remotes/morlic/.: Permission denied
ls: cannot access .git/refs/remotes/morlic/..: Permission denied
total 0
d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
matgb@MatGB-Desktop:~/freeorion$ 
Which implies it is a problem within my git folder as I can get an instant result if I replace morlic with dilvish.

There was something about this on the thread CJ linked, I'll see if that helps.

EDIT: It did, simply deleting refs/remotes/morlic and then running fetch sorted it all out.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: The Git/GitHub Questions, Answers and Howto Thread

#137 Post by adrian_broher » Mon Apr 04, 2016 8:13 am

MatGB wrote:EDIT: It did, simply deleting refs/remotes/morlic and then running fetch sorted it all out.
Probably refs/remotes/morlic didn't have the x permission set. This is required on directories to list their contents.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Cjkjvfnby
AI Contributor
Posts: 460
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#138 Post by Cjkjvfnby » Mon Apr 04, 2016 10:53 am

New github feature, will allow to reduce manual rebase for small pull requests

https://github.com/blog/2141-squash-your-commits
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 5000
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#139 Post by Vezzra » Mon Apr 04, 2016 11:40 am

Thanks for the hint, that's an important new feature, and also requires a decision on future policy. Right now, the feature is enabled in the settings (aparently github decided that to be the default). Dear fellow devs, shall we employ that feature or restrict to classic merge commits? I'd prefer to leave the new feature enabled.

User avatar
adrian_broher
Programmer
Posts: 1082
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: The Git/GitHub Questions, Answers and Howto Thread

#140 Post by adrian_broher » Mon Apr 04, 2016 11:45 am

Vezzra wrote:Thanks for the hint, that's an important new feature, and also requires a decision on future policy. Right now, the feature is enabled in the settings (aparently github decided that to be the default). Dear fellow devs, shall we employ that feature or restrict to classic merge commits? I'd prefer to leave the new feature enabled.
Both options still sound horrible in terms of keeping a clean and consistent and yet information rich history.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 5000
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#141 Post by Vezzra » Mon Apr 04, 2016 11:53 am

adrian_broher wrote:Both options still sound horrible in terms of keeping a clean and consistent and yet information rich history.
Yeah, why they don't just offer the standard ff-merge where possible remains a mystery, but we've to work with what we got.

Of course, we could make it a policy that whenever a ff-merge of a PR is possible, don't merge via the github web UI, but use your local git client. That would give us nice ff-merges.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12446
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: The Git/GitHub Questions, Answers and Howto Thread

#142 Post by Geoff the Medio » Mon Apr 04, 2016 2:38 pm

Vezzra wrote:Of course, we could make it a policy that whenever a ff-merge of a PR is possible, don't merge via the github web UI, but use your local git client. That would give us nice ff-merges.
But waste a lot of time and mental energy, and probably lead to broken / badly done commits, similar to my numerous failures to use git properly over the months...

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#143 Post by LGM-Doyle » Mon Apr 04, 2016 3:02 pm

My two cents.

Go with the richer history.

Don't squash commits.
Squashing 6 commits into 1, means that next week it is difficult to undo the one sketchy commit.

Keep the time stamps.
When you look at the history you can see where the branch started and finished(merged).
You can see the two month gap and guess that the bug is in the first commit after the break.

The only disadvantage to a rich history is if you try to look at it or think of it as a linear history (git log).
Then it looks like chaotic editing, because the individual branches are interleaved .
Forcing a linear history causes the same effect.
Reality is a dozen people working concurrently. Let the record reflect that reality.

Make sure new devs are aware of a viewer that shows the rich history.

Git Feature Request:
I wish git had merge messages, like a commit message for an entire feature branch that summarizes the
intent of all the changes in the branch/merge. Maybe it is already there and I don't know about it.

Don't hold me to my own standards/rules.
I regularly throw little fixes into a commit, because I feel they are too small to warrant a whole commit, whole branch, or whole design review.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#144 Post by MatGB » Sat Apr 09, 2016 9:26 am

I think a case-by-case approach is better, sometimes rebasing at the contributor end can cause problems and when it's a simple, for example, "fix typo" commit you add zero to the history by keeping that as a separate commit. When I'm doing something like, for example, the current fighter balancing I'm going through, I'm going to be tweaking various numbers and, on occasions, needing to make a commit for my WIP that's only there so that my Git client lets me update the branch with work others have done.

It would make a lot of sense to squash this lot into one Add cache by session function by Cjkjvfnby · Pull Request #585 · freeorion/freeorion and given we can easily do so it would be less work and more useful to be able to do it.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

LGM-Doyle
Programmer
Posts: 219
Joined: Mon Feb 29, 2016 8:37 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#145 Post by LGM-Doyle » Sat Apr 09, 2016 7:40 pm

MatGB, Are you aware to "git stash save"? It creates a temporary off-branch commit containing all of the changes in the working directory. After you have git stashed you are left with a clean directory and you can pull, change branches whatever. When you want your changes back you can "git stash pop" and it restores them on top of whatever branch you are now working on. Stashes don't show up in the log.

User avatar
Cjkjvfnby
AI Contributor
Posts: 460
Joined: Tue Jun 24, 2014 9:55 pm

Re: The Git/GitHub Questions, Answers and Howto Thread

#146 Post by Cjkjvfnby » Sat Apr 09, 2016 9:31 pm

How this should be developed with project git workflow.

https://github.com/freeorion/freeorion/pull/587

This branch contains changes by MatGB and Morlic-fo. I want to add some changes too (better via PR).

It will be nice if this branch will be up to date with master.

I don't see easy way to maintain this without merges.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 5000
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#147 Post by Vezzra » Sun Apr 10, 2016 5:50 pm

Geoff the Medio wrote:
Vezzra wrote:Of course, we could make it a policy that whenever a ff-merge of a PR is possible, don't merge via the github web UI, but use your local git client. That would give us nice ff-merges.
But waste a lot of time and mental energy, and probably lead to broken / badly done commits, similar to my numerous failures to use git properly over the months...
Yeah, I'm aware of that, which is why my suggestion was only half-serious anyway. ;)

User avatar
Vezzra
Release Manager, Design
Posts: 5000
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#148 Post by Vezzra » Sun Apr 10, 2016 5:57 pm

LGM-Doyle wrote:Git Feature Request:
I wish git had merge messages, like a commit message for an entire feature branch that summarizes the
intent of all the changes in the branch/merge. Maybe it is already there and I don't know about it.
Correct me if I'm wrong, but the merge commit has a commit message like every other commit, where you can put in your summary - no?

User avatar
Vezzra
Release Manager, Design
Posts: 5000
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#149 Post by Vezzra » Sun Apr 10, 2016 6:20 pm

Well, back on the topic of the new github "squash and merge" feature: I think Mats suggestions is reasonable. Leave the feature enabled, but only use it in the rare cases where it's obviously the better choice. IMO, this would be:
  • Whenever there is a main commit that is just followed by a few minor commits which only fix some typos or small bugs, but don't really "add" to the history, so to speak.
  • As it seems that this "squash and merge" option actually does a rebase and ff-merge of the PR branch, it should probably be used whenever the branch of a PR consists of a single commit. In this case no history will be "lost" (as no actual squashing of commits is going to happen), but we get a linear history (no more of those single commit branches in the history).
Does this meet general approval?

User avatar
Vezzra
Release Manager, Design
Posts: 5000
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: The Git/GitHub Questions, Answers and Howto Thread

#150 Post by Vezzra » Sun Apr 10, 2016 6:26 pm

Cjkjvfnby wrote:How this should be developed with project git workflow.

https://github.com/freeorion/freeorion/pull/587

This branch contains changes by MatGB and Morlic-fo. I want to add some changes too (better via PR).

It will be nice if this branch will be up to date with master.

I don't see easy way to maintain this without merges.
I have already replied to that proposal on github, see there.

To summarize it here: we could make an exception to our "no merge" policy for that branch, as it's not a typical PR branch. To avoid the issues when finally merging into master, a final merge of master into the branch and cleaning up of any conflicts that remain should be done before merging the branch into master. IMO that should take care of all the problems - but I might be wrong. Marcel? Do you think that will work/is a sound policy?

Post Reply