The git save tries to generate a nice commit message based on the most
recent dive, but stupidly didn't check whether that dive was in a trip
or not, and unconditionally used the trip pointer to see if there was a
trip location.
Which works well enough if you always generate trips, but is an
unmitigated disaster otherwise. Oops.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I stupidly used "weekday()" without realizing we localize it. And we
really don't want to make save formats be localized (we don't localize
decimal numbers etc either).
This fixes the git save format to just use a hardcoded weekday list.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of just having "Created by subsurface <version>", put the number
of dives and the location of the last dive in the message. That makes
things like "gitk" show a much more useful view of what actually got
saved.
We still save the subsurface version in the body of the message, because
that is interesting and relevant information. It's just not the
*primary* relevant information.
Anyway, with this, a git commit message might looke something like
dive 474: North West Point (Christmas Island)
Created by subsurface 4.0.96-17-g649e9ed89d9d
which is much more relevant for the common case of adding new dives at
the end.
Of course, if the reason for the save is that you edited old dives, the
relevance of the commit message telling you the number of dives you have
in the log and the dive number is questionable. But then you have to
look at the actual diff to see what's going on.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a preferences setting, it should belong to the preferences
structure.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to always just commit as "subsurface@hohndel.org" because
libgit-19 doesn't have the interfaces to do user name lookup. This does
better if you have libgit-20, using "git_signature_default()" to get the
actual user that does the saving.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The userid of Subsurface Webservice can be included in locally saved xml
files and git repository.
For xml files, it is stored in userid tag. For git repo, it is stored
in 00-Subsurface file present in the repo.
Preference dialog and webservice dialog modified to include option
for saving userid locally.
In case of difference in default userid and userid in local file,
some semantics are followed. These can be referred to here:
http://lists.hohndel.org/pipermail/subsurface/2014-April/011422.htmlFixes#473
Signed-off-by: Venkatesh Shukla <venkatesh.shukla.eee11@iitbhu.ac.in>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Never ever use '%f' to write floating point data to a file. The stupid
locale handling creates useless comma-infested output in some locales.
Instead use one of our clever helper functions to do the right thing.
Original patch by Gehad, modified by Linus to be a little more generic.
Signed-off-by: Gehad elrobey <gehadelrobey@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the git object save logic also check out the changes in the
working tree and index if the branch we save to is checked out. It used
to be that we would just update the object store (and the branch ref, of
course), but leave any checked-out state untouched.
Note that if the working directory is dirty (ie you have made changes by
hand and not committed them), the checkout will skip any dirty files and
report it as a warning to the user. However, the save still succeeds
(since the _real_ save goes to the backing store).
NOTE NOTE NOTE! Both loading and saving very fundamentally work on the
git object store level, and if you are working with a checked-out branch
and make modifications to the working tree, saving will not touch those
dirty files (so that you can try to recover your edits manually in the
working tree), but it's worth pointing out that subsufrace loading state
will totally ignore the working tree.
So the only way to make subsurface *see* your changes is to commit them.
Having edited state checked out in the working tree will only confuse
you when subsurface first ignores it on reading, and then refuses to
touch the checked-out state on writing.
Put another way: working with a checked-out branch is now _possible_,
but you need to be aware of the limitations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes "is_git_repository()" return non-NULL for all file names that
match the git name pattern, even if we don't find an actual git
repository there. That way, we won't fall back to writing out an XML
file with an odd filename.
If there is no actual git repository, we return a special invalid dummy
pointer, and then the git reading and writing routines will catch it and
return the appropriate error.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the error string just be an internal "membuffer", which the
GUI can fetch and show when errors occur. The error string keeps
accumulating until somebody retrieves it with "get_error_string()".
This should make any write errors actually show up to the user.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes subsurface remember the git source commit of the dive data.
If you save to an existing branch, subsurface will now complain and
refuse to save if you try to save if the existing branch is not related
to the original source. That would destroy the history of the dive
data, which in turn would make it impossible to do sane merging of the
data.
If you save to a new branch, it will see if the previous parent commit
is known in the repository you are saving to, and will save parenthood
information if so. Otherwise it will save it as a new parentless commit
("root commit" in git parlance).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead, just encode the git repository information in the filename.
We want to make it much harder to make it match a real filename, but to
still allow easy browsing with the file manager interface. So the git
repository "filename" format is the path to the git repository
directory, with the branch name encoded as "[branch]" at the end rather
than the "path:branch" format that we used in the descriptor file.
[ For example, on Windows, a filename like "c:\my.xml" could be
interpreted as the branchame "\my.xml" in the repository in the
directory "c" ]
In particular, with this model, no filename that ends with ".xml" could
possibly ever be considered a git repository name, since the last
character of a git pathname is always ']'.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the newly created save tree is identical to the parent commit tree,
don't bother creating a new commit. We are already fully up-to-date.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I didn't think that one through: the version string is already saved in
the commit message, and so saving it in the tree object is redundant.
Now a little redundancy doesn't hurt, but having the tree object depend
on th esubsurface version _does_ end up being annoying: it means that as
you update the subsurface version, doing a data save will result in a
different tree SHA1 even if none of the data changed.
Which doesn't actually matter right now, since we always create a new
commit anyway, but my plan was to skip the commit creation if nothing
changed in the tree. And saving the version string defeats that if you
are a subsurface developer and the subsurface version keeps changing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So this is totally unrelated to the git repository format, except for
the fact that I noticed it while writing the git saving code.
The subsurface divetag list handling is being stupid, and has a
initial dummy entry at the head of the list for no good reason.
I say "no good reason", because there *is* a reason for it: it allows
code to avoid the special case of empty list and adding entries to
before the first entry etc etc. But that reason is a really *bad*
reason, because it's valid only because people don't understand basic
list manipulation and pointers to pointers.
So get rid of the dummy element, and do things right instead - by
passing a *pointer* to the list, instead of the list. And then when
traversing the list and looking for a place to insert things, don't go
to the next entry - just update the "pointer to pointer" to point to
the address of the next entry. Each entry in a C linked list is no
different than the list itself, so you can use the pointer to the
pointer to the next entry as a pointer to the list.
This is a pet peeve of mine. The real beauty of pointers can never be
understood unless you understand the indirection they allow. People
who grew up with Pascal and were corrupted by that mindset are
mentally stunted. Niklaus Wirth has a lot to answer for!
But never fear. You too can overcome that mental limitation, it just
needs some brain exercise. Reading this patch may help. In particular,
contemplate the new "taglist_add_divetag()".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a top-level "00-Subsurface" file that sorts first in the git
tree, and contains version information, dive computer nicknames and
settings. Although right now the settings are just the autogroup thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oops. Really stupid bug in event saving, resulting in bad event lines,
that I didn't notice until I started trying to parse them.
The argument order is a bit mixed up, which is partly why this happened.
But considering that this is the worst bug I've hit so far in the saving
code, I guess I shouldn't complain too much.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We want to make sure that we load them in the same order we save them,
and while using the hash made the divecomputer names unique, it didn't
sort them. You couldn't tell with just one or two dive computers, but
if you have three or more dive computers on a dive, the order of any but
the first ended up depending on the ordering of the unique hash
extensions.
So just append a numeric index instead of relying on the hash to make
the names unique. But skip the index if there is just one dive
computer.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It doesn't actually parse the files themselves, but it does walk the
object tree and print out the dives and trips it finds.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of hardcoding the regular file mode (0100644 is the traditional
Unix S_IFREG file mode with -rw-r--r-- protections), use
GIT_FILEMODE_BLOB (and GIT_FILEMODE_TREE for 040000 - S_IFDIR).
The numbers were historically indeed the regular S_IFREG/S_IFDIR values,
but since those aren't portable, git ended up defining their own.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This fixes up the writing of the git format to the point that it might
be getting close to complete. In particular:
- Add subsurface version information into commit message as requested by Dirk
- Fix missed string quoting ('\' needs to be quoted as '\\')
- rename "git_save_error()" as "report_error()", since we'll want to
use this for the loading code too.
- Improve on dive and trip name generation
- create a date-based directory hierarchy
- save dive computer data as individual files
- actually save the trip information
There might be further changes as I start to actually *read* the git
files, of course.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add the following to your qmake command line and things should compile
again:
qmake ... CONFIG+=libgit21-api
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Linus was wrong - the change to the API happened after 0.20 was released.
So libgit2 0.20 still needs the fix.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This saves the dive data into a git object repository instead of a
single XML file.
We create a git object tree with each dive as a separate file,
hierarchically by trip and date.
NOTE 1: This largely duplicates the XML saving code, because trying to
share it seemed just too painful: the logic is very similar, but the
details of the actual strings end up differing sufficiently that there
are tons of trivial differences.
The git save format is line-based with minimal quoting, while XML quotes
everything with either "<..\>" or using single quotes around attributes.
NOTE 2: You currently need a dummy "file" to save to, which points to
the real save location: the git repository and branch to be used. We
should make this a config thing, but for testing, do something like
this:
echo git /home/torvalds/scuba:linus > git-test
to create that git information file, and when you use "Save To" and
specify "git-test" as the file to save to, subsurface will use the new
git save logic to save to the branch "linus" in the repository found at
"/home/torvalds/scuba".
NOTE 3: The git save format uses just the git object directory, it does
*not* check out the result in any git working tree or index. So after
you do a save, you can do
git log -p linus
to see what actually happened in that branch, but it will not affect any
actual checked-out state in the repository.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
