Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Uemis integration #51

Merged
merged 2 commits into from
Oct 3, 2011
Merged

Uemis integration #51

merged 2 commits into from
Oct 3, 2011

Conversation

dirkhh
Copy link
Collaborator

@dirkhh dirkhh commented Oct 3, 2011

Umm - I don't know why it offers you the first commit again - you pulled that already from the bugfixes, didn't you? I'm sure this is because I did something strange with my branches locally... I had first done this commit in the uemis integration branch but then wanted to offer this to you interdependently from that as it really just fixed a bug...
How can I tell github to only offer you that last commit that has what I actually want to push?

@dirkhh
Add working pressure to uemis tank data
09ef299 
Turns out they use 202.6bar as default working pressure. WTF?
Also I had misunderstood the way I should record the pressure internally
(which happened to work since I didn't set the working pressure). This is
now fixed as well.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
@dirkhh
Much nicer implementation of uemis sample parsing - and add events, too
0c343f2 
This is something I wanted to do for a while. Every uemis sample is simply
a packed structure with no padding. Instead of grabbing random bytes from
the middle of an unstructured data blob let's just define the structure
and access its members.

And while we do that, add support for the more useful uemis events as
well.

A couple of the warnings are disabled by default (compile time flag) as
they are just crazy - any normal dive will give you dozens and dozens of
speed warnings. Same goes for the PO2 green warning (I haven't looked but
this seems to trigger on a PO2 over 1.0 or something). Completely useless
and just hides actually useful info.

I still want to redo the way we visualize events in general - just
printing the text ontop of the profile really is suboptimal. Especially as
the uemis really seems to love to repeat several of the warnings quite
frequently.

Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
@torvalds
Copy link
Collaborator

torvalds commented Oct 3, 2011

On Mon, Oct 3, 2011 at 12:36 PM, Dirk Hohndel
reply@reply.github.com
wrote:

Umm - I don't know why it offers you the first commit again - you pulled that already from the bugfixes, didn't you? I'm sure this is because I did something strange with my branches locally... I had first done this commit in the uemis integration branch but then wanted to offer this to you interdependently from that as it really just fixed a bug...
How can I tell github to only offer you that last commit that has what I actually want to push?

You cannot ever just "pull one commit".

That operation makes no sense. A commit does not exist in a vacuum, it
always comes with full history. Only crazy crap source control thinks
that commits are independent from what led up to them. A commit is not
just "the commit" - it's every single commit that is reachable from it

  • every parent of the commit is present in a commit.

The way to "pull one commit" is to create a new branch (or modify the
old branch) to only contain the old commit. "git reset --hard "
will reset the branch state, and "git rebase -i " will give you
the option to re-order or edit commits starting at . But the
rebase will create new commits - they have absolutely no connection
to the old commits they come from, except that the new commits will
obviously share a lot of common details.

And "git rebase -i" is very useful, but it's only useful if you really
fundamentally understand that commits are not "the commit message
and the patch". Commits are the WHOLE PROJECT. A commit in git is not
a "patch". It's the full state of the project tree at the time of the
commit, and the full history. "git rebase" is basically rewriting
history - which is useful, but at the same time it doesn't really
change that old history - it literally creates a totally new set of
commits. The old commits still exist - they may just not be easily
reachable any more, because you may have thrown away the pointer to
them.

At all times, think of git as a DAG of commits. No commit ever has any
individual existence (except the root commit that has no parents).

                      Linus

@torvalds torvalds merged commit 0c343f2 into subsurface:master Oct 3, 2011
@p-neves p-neves mentioned this pull request Aug 29, 2018
Closed
3 tasks
@mturkia mturkia mentioned this pull request Jul 21, 2021
Merged
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@dirkhh @torvalds