Using Git how do I find changes between local and remote

Question

Let's say I'm getting some JSON in the format of...

"fellowPlayers": [
            {
               "championId": 110,
               "teamId": 100,
               "summonerId": 34258805
            },
            {
               "championId": 9,
               "teamId": 200,
               "summonerId": 19923759
            },
           ...
]

...that can have a variable # of entries, but always those 3 attributes, 2 of which should map to other tables (championId and summonerId), how would I want to define a table/model in Django to do this?

If this can't be directly done, how would you suggest handling such a situation? My initial thought was to hardcode in a # of fields based on what I expect the maximum # of entries to be (around 11), but that approach seems like it could be improved on a lot, although 11 isn't too bad in terms of hardcoding.

To clarify, and give some more context: I have a model that will be keeping track of historical match data in a game. This includes a large # of details that are match-specific, like points earned, kills, etc. championId and summonerId refer to in-game character used for the match and the player that used said character for that match, respectively. There are only 2 possible values for team id (global constants) and these won't relate to any other table. championId and summonerId will relate to tables tracking champions and players, respectively.

The problem I am having lies in the model (let's call it a MatchHistory model that stores stats for a single match) that actually "contains" the listing of fellowPlayers, because games can have a variable # of players in them, from 1 to 12. So for any given match, I can get a bunch of known-size fields of match statistics which are fine to handle, but I don't know how to organize this when considering the unknown # of players, and relating their info to this model.

I stumbled upon https://groups.google.com/forum/#!searchin/django-users/storing$20lists$20model/django-users/iOQs7qNfqBI/GuS5IlJ4qpUJ while searching for a solution to this problem, and it looks like what I am trying to do is not really supported by SQL, as it analogous to storing a list of variable length in SQL. Maybe someone can elaborate on this "incompatibility" such that I might determine if it applies to what I'm doing.

If any more information is needed please comment.

Solution 1

Git can't send that kind of information over the network, like Hg can. But you can run git fetch (which is more like hg pull than hg fetch) to fetch new commits from your remote servers.

So, if you have a branch called master and a remote called origin, after running git fetch, you should also have a branch called origin/master. You can then get the git log of all commits that master needs to be a superset of origin/master by doing git log master..origin/master. Invert those two to get the opposite.

A friend of mine, David Dollar, has created a couple of git shell scripts to simulate hg incoming/outgoing. You can find them at http://github.com/ddollar/git-utils.

Solution 2

Starting with Git 1.7.0, there is a special syntax that allows you to generically refer to the upstream branch: @{u} or @{upstream}.

To mimic hg incoming:

git log ..@{u}

To mimic hg outgoing:

git log @{u}..

I use the following incoming and outgoing aliases to make the above easier to use:

git config --global alias.incoming '!git remote update -p; git log ..@{u}'
git config --global alias.outgoing 'log @{u}..'

Solution 3

Not a full answer but git fetch will pull the remote repo and not do a merge. You can then do a

git diff master origin/master

Solution 4

1. Use "git log origin..HEAD"

2. Use "git fetch" followed by "git log HEAD..origin". You can cherry-pick individual commits using the listed commit ids.

The above assumes, of course, that "origin" is the name of your remote tracking branch (which it is if you've used clone with default options).

Solution 5

There's also this, for comparing all branches:

git log --branches --not --remotes=origin

This is what the git log man page says about this:

Shows all commits that are in any of local branches but not in any of remote tracking branches for origin (what you have that origin doesn’t).

The above is for outgoing. For incoming, just swap:

git log --remotes=origin --not --branches

View more solutions

Comments

[Roman Starkov]

Looking at the answers, there seems to be some confusion as to what hg incoming and hg outgoing actually do. The nearest Git equivalent I found is the --dry-run option. Just git pull --dry-run and you'll see a list of all the things that need to happen.

[Alex]

Could you add a little bit? The way I understand it, you'll somehow receive your JSON response, and you want to automatically unpack it and store it? If that's correct, is the general model setup in the answer below correct? i.e. you'll have a FellowPlayer with ForeignKeys to both champion and summoner? I think I understand what you're asking but just want to make sure I have the models part right.

[Kreychek]

This is proving trickier to communicate than I anticipated. I have revised my post to include more information.

[plindberg]

(And if you’re not tracking the remote branch, it’s “git log origin/master..HEAD”.)

[robinst]

"origin" is not the name of the remote tracking branch, it's the name of the remote. And just specifying the remote name doesn't work, you have to specify the remote tracking branch, which would be origin/master.

[Henrik]

git log ..@{u} gives me these errors. (I have both origin and an upstream repository in my git config). error: No upstream branch found for '' error: No upstream branch found for '..' error: No upstream branch found for '..' fatal: ambiguous argument '..@{u}': unknown revision or path not in the working tree. Use '--' to separate paths from revisions

[Richard Hansen]

You'll get those errors if your local branch isn't configured with an upstream. To fix, run git branch --set-upstream foo origin/foo.

[Roman Starkov]

git log @{u}.. lists every single change in the repo for me. There's no way they don't exist yet.

[Richard Hansen]

@romkyns: It's possible your local branch has the wrong remote branch configured as the upstream. Make sure git rev-parse --symbolic-full-name @{u} prints the appropriate remote reference. Also, git log @{u}.. shows the commits that aren't reachable by the upstream branch, which can include commits that are already in the remote repository (if they are reachable by a different reference). This will happen right after you merge in an already-pushed branch.

[Roman Starkov]

@RichardHansen I'm afraid I'm too noob to know what would be appropriate for a remote reference, however this was a freshly cloned repo on which I did only a checkout <somebranch> and merge <otherbranch>. At this point, I did the log @{u}.. and saw every change listed.

[Richard Hansen]

@romkyns: If by "saw every change" you mean that you saw all of the commits from <otherbranch>, then this is expected. Because you just did the merge, the commits on <otherbranch> are now reachable from your local <somebranch> but aren't yet reachable from the remote origin/<somebranch>. Thus, these commits are "outgoing" to the remote origin/<somebranch> branch. Even though they won't be new to the remote repository, they'll be new to that remote branch.

[Richard Hansen]

@romkyns: I realize this is confusing; Git is inherently hard to understand. I highly recommend reading Pro Git -- it'll help you understand this stuff.

[Roman Starkov]

I see, your comment makes it clear. My confusion stems from the fact that hg outgoing does not do that. It just lists commits that need to be sent to the remote repo. I think git push --dry-run is much closer in spirit to hg outgoing.

[anatoly techtonik]

You still need to git fetch all changes before executing git log ..@{u} for this to work.

[chris]

Sorry, I overlooked that this was already said as a comment to the OP.

[Kreychek]

I have revised the OP to hopefully better communicate what I am trying to do. I really appreciate the effort :) I will try to wrap my head around structuring things this way and accept if it makes sense to use the DB in this manner.

[sergiuz]

I updated my answer again. This is the way to do it in Django. You have a match history which can contain more fellow players. That is a one to many relation. And the queries are made backwords. I am pretty sure you can get the expected result with this solution.

[Nick Grealy]

Worked for me (but other way around) - git diff origin/master master

[Myk Melez]

@anatolytechtonik Indeed. The suggested incoming alias includes a git remote update -p, which fetches changes. But I'd rather git fetch instead, to only fetch changes for the current branch's upstream: git config --global alias.incoming '!git fetch && git log ..@{u}'