ToDo list

[jarun]

Rolled from #306.

Ready for next release

• custom key-plugin keybinds to run plugins directly
• plugin changes:
  • moclyrics - show lyrics of the track currently playing in MOC
  • vidthumb - show video thumbnails in terminal
  • mediainf - show media info (decoupled as a plugin)
  • dups - list duplicate files in the current directory
  • oldbigfile - list large files by access time
  • mocplay - now detects if a track is playing or not
  • organize - categorize files and move to respective directories
  • fzy-edit merged into fzy-open
  • checksum - fixed POSIX compliance issues
  • boom plays music in MOC by default
• Leader key combinations:
  • Lead' to jump to first file in dir
  • Lead] go to next active context
  • Lead[ go to prev active context
  • Lead. toggle show hidden files
• function key mappings: F2 (rename), F5 (redraw), F12 (run plugin)
• auto-proceed to next file on cherry-pick in selection mode
• make selection based archives lose path prefix for files in current dir
• changed duplicate file workflow
• new option -o to use file access time throughout the program
• new option -o replaces config NNN_RESTRICT_NAV_OPEN
• new option -t replaces config NNN_NO_AUTOSELECT
• new option -r replaces config NNN_OPS_PROG
• removed the wild load option (-w)
• fix CPU using %100 by nnn #225 (thanks @KlzXS)
• fix tar/bsdtar always creating tar archives (and not by suffix)
• fix single mouse click to select file not working
• fix symlink to dir removed on batch rename
• fix: set detail mode with program option -S
• libreadline .history file moved to nnn config directory
• revamped wiki

Proposed features and tasks (up for grabs)

• session support (max 4 directories)
• script to duplicate selection in respective directories
• refactor function browse()

Anything else which would add value (please discuss in this thread).

List of completed features and tasks.

[jarun]

@0xACE & @KlzXS how does the revamped wiki look? I spent half a day on it.

[0xACE]

I read Home.md from top to bottom and it looks ok.

I quickly skimmed through the other articles and they seem fine. I like that advanced configuration has been moved to an entirely separate document, this keeps the noise down for new users.

I tried recalling how it was when I started using nnn and what resources I used. And from what I can recall I went immediately to the wiki we have on github, and after copying the cd-quit thing I later looked up environment variables and flags in man nnn and put them in my ~/.bashrc. (Idea: should the wiki list the flags and environment variables you could put in ~/.bashrc?). After that I adopted it into my workflow and added changes as I see fit during my learning experience.

Today I'm pretty set and even pre-compile my flags as hardcoded defaults for nnn. Currently I'm only developing new features/functions that I think are missing. (Bringing up my latest hack at the end of my post)

Oh and btw TIL about nlaunch. I always ignored it thinking it was a useless script, but now I can hit = and have fzf act as my dmenu of sorts :).

I don't know if this is possible but can nnn act as a save file as prompt for browsers? Like when you save a file with firefox, could nnn be used to pick path and filename? (doubt I would use it but I'm curious)

Well I've been quiet but still been working on nnn. My latest hack revolves around this:

c()
{
   if [ -z "$NNN_BMS" ]; then
      return 1
   fi
   target=$(echo "$NNN_BMS" | sed -e "s|.*;\?$@:\([^;]*\);\?.*|\1|" -e "s|\~|$HOME|")
   if [ -d "$target" ]; then
      cd "$target"
   fi
}

This allows you to cd into a nnn bookmark with c <bookmark> in your terminal.

along with it I also wanted to make nnn understand bookmark shortcuts as arguments to the program. (WARNING: my bashisms is in great need of rehearsal, but atleast the concept proves its point)

n()
{
        NNN_TMPFILE=${XDG_CONFIG_HOME:-$HOME/.config}/nnn/.lastd
        if [ -n "$1" ]; then
           if [ -d "$@" ]; then
              args="$@"
           else 
              args=$(echo "$NNN_BMS" | sed -e "s|.*;\?$@:\([^;]*\);\?.*|\1|" -e "s|\~|$HOME|")
              if [ ! -d "$args" ]; then
                 args=""
              fi
           fi
        else
           args=""
        fi
        if [ -n "$args" ]; then
           nnn -sdHt "$args"
        else
           nnn -sdHt
        fi

        if [ -f $NNN_TMPFILE ]; then
                . $NNN_TMPFILE
                rm -f $NNN_TMPFILE > /dev/null
        fi
}

This allows you to n <bookmark key> to launch nnn in the bookmarked directory. The if-statements can be reworked to bookmarks are prioritized and that if someone wants to for example reach ./d instead of the bookmark d:~/docs you could move the bookmark to be the first check and have the user access the directory d with ./d. (Sorry for the poor explination it takes more time to explain it than a user trying it out.) (Also this script is in great need of rewriting, it's very poor and could be simplified, but this was the best I could do in 30seconds... (If someone refactors the code, please do share it as I rarely have access to a pc to actually develop nice things.)

Spent more time on writing the message than I intended, so I have to abruptly quit and just send the message and hope for the best. Cheers!

[jarun]

I don't know if this is possible but can nnn act as a save file as prompt for browsers?

Can you try https://github.com/jarun/nnn/wiki/Advanced-use-cases#configure-as-default-fm? (Go through it completely.)

This allows you to cd into a nnn bookmark with c in your terminal.

You already have -b for that. How about nnn -b key?

[KlzXS]

Do Why fork? and The name need to each have their own page? And then there is Comparison: nnn vs. noice. Three pages talking about nnn and noice, two of which are one sentence long. Can't they be pasted at the top of Comparison: nnn vs. noice as their own sections?

[jarun]

Makes sense. I'll do that now.

[0xACE]

I don't know if this is possible but can nnn act as a save file as prompt for browsers?

Can you try https://github.com/jarun/nnn/wiki/Advanced-use-cases#configure-as-default-fm? (Go through it completely.)

Yeah I think I'll try it when I get access to a computer I own...

This allows you to cd into a nnn bookmark with c in your terminal.

You already have -b for that. How about nnn -b key?

Haha, now I feel bad. well that makes the n() function easier :D

[jarun]

I have updated the wiki, consolidated the 3 pages into one.

[KlzXS]

I can't really tell by looking at the code since the function is huge, is it safe to use sb at the top of nochange in browse()? I'm looking for a way to fix the bug where nested sessions cause 100% CPU use when the parent terminal is closed. #225

The simplest way to fix it is to kill the process when the terminal closes and the simplest way to check that is to see how many hard links point to stdin and stdout which point to a tty file in /dev/. When the terminal closes the number of hard links (sb.st_nlink) drops to 0. This is tested on ArchLinux and NetBSD, but should work on all POSIX compliant systems.

[jarun]

is it safe to use sb at the top of nochange in browse()?

completely.

The simplest way to fix it is to kill the process when the terminal closes

Which means a stat() every time we go for nochange. I am not sure of the performance implications. I wanted to avoid unwanted side-effects so I left the issue unaddressed given it's not really something very pressing. Are you facing this often?

[jarun]

@KlzXS I went through the issue thread. The problem with the proposed approach is the control never returns to nnn from the spawned child. So the check will never happen when this scenario is encountered.

You can still use POSIX threads to spawn a thread and check in it (periodically perhaps?) if the main thread has exited. Though I still believe the solution is stronger than the problem with this approach. you can surely check it out.

[KlzXS]

The problem with the proposed approach is the control never returns to nnn from the spawned child

What do you mean? If I detect that my terminal has closed I exit. The parent would then get notified that the child exited and would do whatever it is that it should do.

As for the performance issues, I have tried triggering nochange as much as possible and still couldn't get any meaningful CPU usage. Disk I/O is also not a problem since it's not a real problem. It's not a heavy function to call. We also call getppid() and access() every time.

[jarun]

If I detect that my terminal has closed I exit

Where are you planning to detect it?

To elaborate a little: The child is a spawned process/task/script. The parent is nnn. nnn waits for the child to complete. If the terminal is closed and the child is a terminal utility are you saying the child process will exit and control would return back to nnn? If that were the case, the current check of getppid() would suffice, no?

[KlzXS]

Let's make sure we are on the same page. You know that:

• the child is the one that uses 100% CPU, not the parent
• we are talking about nnn as both child and parent. Nested nnns.
  I've been able to reproduce this with only one other combination of programs and that is nnn as the parent and ranger as the child. Curiously ranger-ranger and ranger-nnn exit just fine.
• the problem in the child nnn is that is gets caught in an infinite loop with no way to exit basically only doing ++idle. It tries to call getch() but when the terminal is closed it returns -1 instantly.

The way to fix this is to see if the terminal is closed. As all things in Unix, a terminal is a file, in this case it's one of the files in /dev/pts/. While the terminal is open there exists 1 link to it, the filename in /dev/pts/. When it closes the number of links is 0. We can call stat on stdin to see how many links there are. If there are none that means the terminal is closed, we can't get any input from it, so we should exit.

Most terminal utilities seem to have a way of detecting when read and/or write to the terminal and exit, I've tried everything that came to mind.

[jarun]

Now I see. I never paid attention to the child process not exiting issue and considered REPL programs in a generic way.

Yes, I agree we can fix that in nnn. How about checking the return value from getch() (it will return -1 or ERR) and using that to exit. That way we will not need any additional checks.

[0xACE]

Yes, I agree we can fix that in nnn. How about checking the return value from getch() (it will return -1 or ERR) and using that to exit. That way we will not need any additional checks.

From the manual of getch():

Programmers concerned about portability should be prepared for either of two cases:
(a) signal receipt does not interrupt getch;
(b) signal receipt interrupts getch and causes it to return ERR with errno set to EINTR.

I guess case (b) would require getch() == ERR && errno != EINTR... But I'm not sure what the correct way to deal with this problem is.

[jarun]

(a) signal receipt does not interrupt getch;

This case cannot be handled anyway.

[KlzXS]

We can't use return of ERR as the condition for exiting since that's what it returns when it times out.

[jarun]

... and there's no guarantee it will set and errno it seems from the man.

Please raise the PR and let's test it out on systems we have.

[0xACE]

Yes, what I meant was: getch() == ERR isn't enough, it should also include && errno != EINTR. But even with that the manual specifies:

returns ERR if the window pointer is null, or if its timeout expires without having any data,
or if the execution was interrupted by a signal (errno will be set to EINTR).

EDIT: saw your posts now that I sent this. didn't mean to duplicate your statements...

[jarun]

I tested on Ubuntu 18.04 and the getch() return thing is unreliable. So @KlzXS I think we should try the blind check without depending on getch().

[KlzXS]

The "blind check"? What is that referring to, my mind's all over the place, sorry?

[jarun]

blind check

The way to fix this is to see if the terminal is closed. As all things in Unix, a terminal is a file, in this case it's one of the files in /dev/pts/. While the terminal is open there exists 1 link to it, the filename in /dev/pts/. When it closes the number of links is 0. We can call stat on stdin to see how many links there are. If there are none that means the terminal is closed, we can't get any input from it, so we should exit.

[KlzXS]

isatty() also works. Returns 0 when it's closed.

[jarun]

Awesome! Please use that!

[jarun]

Also. please ensure we have a check for the picker mode in which we run nnn in non-tty mode.

[jarun]

The following patch works for me:

diff --git a/src/nnn.c b/src/nnn.c
index 6e52978..bd0de28 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -3447,6 +3447,9 @@ nochange:
                        goto begin;
                }
 
+               if (!isatty(STDIN_FILENO) && !cfg.picker)
+                       return;
+
                sel = nextsel(presel);
                if (presel)
                        presel = 0;
@@ -4790,7 +4793,7 @@ int main(int argc, char *argv[])
        }
 
        /* Confirm we are in a terminal */
-       if (!cfg.picker && !(isatty(0) && isatty(1)))
+       if (!cfg.picker && !(isatty(STDIN_FILENO) && isatty(STDOUT_FILENO)))
                exit(1);
 
        /* Get the context colors; copier used as tmp var */

[KlzXS]

Seems good.

[jarun]

Please add a comment on the check. Please raise the PR. This is an excellent find and fix! I appreciate your effort!

[jarun]

@0xACE can we have the much awaited Wikipedia page for nnn? ;)

[0xACE]

Oh, I right. I will add it to my calender so that I dont forget it again

[jarun]

@0xACE and @KlzXS with the support to run plugins directly, I am considering decoupling mediainfo/exiftool and diminishing this to a plugin. In my understanding, showing media info is not core file manager functionality.

What do you guys think?

[KlzXS]

I personally like when a file manager is able to tell me something more about my files than "it's a video/image", I don't rely on this, it's just handy to have.

But to display this info it uses these program that I didn't have installed by default; I don't know if they come by default on other distros, MacOS or BSDs. So if I need to install a whole program I might as well configure a plugin.

It's up to you.

[jarun]

I personally like when a file manager is able to tell me something more about my files than "it's a video/image", I don't rely on this, it's just handy to have.

Most FMs (if not all) use a third-party program to do this as the number of media formats is overwhelming. So yes, you will have to install a new program (or it is a part of a framework like gnome/KDE).

AFAIK, mediainfo/exiftool will not be installed by default. And they may not be the natural choice for many users who are accustomed to another utility. So, having the capability through a plugin gives the user that choice. Plugins are indicative and the user can modify it to use his/her preferred utility.

@0xACE what do you say?

[0xACE]

Well I think KlzXS put it well:

I don't rely on this, it's just handy to have.

Lately I have grown keen to tools with "batteries included". But I would understand if mediainfo/exiftool are considered to be niche tools. On full blown FMs I tend to rely on them having the ability to list all sorts of metadata when you Right Click > Properties and I guess that would be nice rather than just mediainfo, but I guess maintaining that feature would be a project of itself (the ugly lesspipe.sh hack I provided does provide this feature, it gives great luxury for the user but the code itself feels like a mess).

Personally I do use the m key to view mediainfo and tend to have it installed on my machines. If it disappears I don't think I'll adapt it to my personal configuration as its too much of a hassle for me compared to just ^Omediainfo in the few cases I do use it.

I looked at the related code and it doesn't seem to be cluttered. So if you remove it I see no gain nor loss.

I will be happy with whatever you choose.

[jarun]

Personally I do use the m key to view mediainfo and tend to have it installed on my machines.

You'll have to press xm (or F12m) when it's a plugin. The info will still be in PAGER.

The reason I want to remove it is I feel we don't really need it and the user can have the flexibility to choose his own utility to show media info. He can use mediainfo which will be the default in the plugin as well. It's just an extra keypress (x) for him.

Benefits I see:

• a non-core functionality decoupled
• a somewhat direct program dependency removed. You'll also notice that with this we no more have any utility dependency which is required (other than sshfs which is not the regular use case for most users nowadays)
• 2 keybinds freed up

Right Click > Properties and I guess that would be nice rather than just

How about finding a better utility that shows short and sweet media info (exiftool is shorter than mediainfo) and show that along with file details (D)?

At some point if I get time I might write a simpler media info utility info myself in Python. I don't see any reason why by default mediainfo show show the following data:

Encoded date                             : UTC 2018-09-16T06:54:16Z
Writing application                      : HandBrake 1.1.2 2018091000
Writing library                          : Lavf57.7.2
Writing library                          : x265 2.6:[Linux][GCC 7.3.0][64 bit] 8bit+10bit+12bit
Encoding settings                        : cpuid=1173503 / frame-threads=2 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=2 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=300 / bframes=4 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=15 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=1 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=2 / early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=750 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=5 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.601 PAL
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

For an end user like me, these info doesn't even mean anything.

[jarun]

Maybe I'll make the plugin show short and sweet info. ;)

[KlzXS]

It's rather too detailed. I think a much more concise description would be better. Resolution and format for an image, container, format, resolution, bitrate for video/audio and perhaps some artist metadata if it exists.

exifstool is better but it still prints way too much information. Like, what is this Matrix Structure : 1 0 0 0 1 0 0 0 1? I can't even tell if this is part of the video or audio stream.

a somewhat direct program dependency removed. You'll also notice that with this we no more have any utility dependency which is required (other than sshfs which is not the regular use case for most users nowadays)

Why not remove sshfs as well if it's not something that common?

[jarun]

Why not remove sshfs as well if it's not something that common?

Because we have a nice way to dynamically handle sshfs in nnn. It can be too elaborate. However, for mediainfo, its just 0 or 1 program option.

[KlzXS]

Okay. So what's the plan, remove mediainfo from the core and make a custom plugin to serve media info or use an existing program?

[jarun]

remove mediainfo from the core and make a custom plugin to serve media info or use an existing program?

Right

[KlzXS]

Maybe I should have put a bigger emphasis on that. Would you rather we make a custom thing or just feed (formated) output from a 3rd party program?

[jarun]

For now, I am just calling mediainfo to show the data to the user (same as what we do in the program).

[jarun]

@KlzXS for a shorter and sweeter version can we cleanse and have the following:

https://github.com/zmwangx/storyboard/blob/master/src/storyboard/metadata.py

It's from a co-dev but I am unable to contact him for sometime. Must be very busy.

[0xACE]

How about finding a better utility that shows short and sweet media info (exiftool is shorter than mediainfo) and show that along with file details (D)?

Hehe, I wanted to elude to that, but then I realised the code that has to be maintained for it t work nicely would be too much of an effort considering the effects of portability.

You'll have to press xm (or F12m) when it's a plugin.
a somewhat direct program dependency removed.
2 keybinds freed up

Yeah, when you put it that way, removing m for media info makes sense.

sshfs

I have to mention: sshfs is one of the top-most used feature in my nnn workflow.

Some quirks I have found with sshfs are:

1. Sometimes I get disconnected. I could use the "-o reconnect" but I'm not happy with the default serverkeepalive counts and what not...
2. By default it doesn't use -o follow_symlinks
3. if the remote is already mounted, trying to go back to that folder with cmyphone results in mount failed and not going into the directory (even-tough it's mounted and available)
4. Is there a quick way to reach the mount folder? in my case I have the bookmark m:~/.config/nnn to reach the mount folder.
5. Requires usermanagement to mount and unmount. Imagine just accessing the directory triggered mounting it as a sshfs folder (A bit overkill)

(I sound like I'm nagging, I would fix these problems myself but atm I'm unavailable for bigger development tasks until late september)

I don't see any reason why by default mediainfo show the following data:

To be honest I really use that information. I"m sort of hosting my own media and I need to know what codecs are being used to know if it will run in a webbrowser or if further encoding/decoding will be needed. It also helps with other metadata that I commonly use. (Another tool i also use is called guessit but it mostly has to do with fetching subtitles)

Maybe for a casual user WidthxHeight, movie-length is enough. Do as you please with this, I'll just stick to mediainfo. But remember implementing it to D is likely going to be a cumbersome task.

[jarun]

Sometimes I get disconnected. I could use the "-o reconnect" but I'm not happy with the default serverkeepalive counts and what not

I think you can add the following in ~/.ssh/config

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

Note: TCPKeepAlive is yes by default

By default it doesn't use -o follow_symlinks

You can add your custom NNN_SSHFS_OPTS for this

if the remote is already mounted, trying to go back to that folder with cmyphone results in mount failed and not going into the directory

Without having to store mount info, I think a simpler check would be to see if the dir is empty or not. If it's not empty we can go into the dir.

The caveat is, if the dir is not empty (having local files) and the mount fails. The user has no way to know the mount failed.

Is there a quick way to reach the mount folder?

I am doing what you are doing to reach the config dir. I don't come out of the mount (and use a new context) so I seldom go into that fir manually. :)

Requires usermanagement to mount and unmount. Imagine just accessing the directory triggered mounting it as a sshfs folder (A bit overkill)

User has to provide the name of the remote to mount and unmount. The ssh config is a one time activity. I didn't understand the second part. If you are saying we just select the dir and mount by the dir name, the directory is not created the very first time. Also, that takes the flexibility of being able to mount and unmount on the fly.

To be honest I really use that information.

In that case let's just have mediainfo in the plugin. As I mentioned, the user experience remains the same other than to have to press an extra x.

implementing it to D is likely going to be a cumbersome task

Indeed. And I'm not picking it up right away either.

[KlzXS]

for a shorter and sweeter version can we cleanse and have the following:
https://github.com/zmwangx/storyboard/blob/master/src/storyboard/metadata.py

I actually like the output as it is. It's everything I would want to see about a video/audio/image file.
But if we were to use that I would take just metadata from the whole thing.

[jarun]

Yes, I have kept the output intact.

[KlzXS]

Yes, you kept mediainfo, but I like this thing you mentioned storyboard/metadata.py it just needs to be extracted from the whole project since I see no need for installing the whole thing to only use one script. It contains all the relevant info without the verbosity of mediainfo.

The only problem is that compared to mediainfo and ffprobe it is noticeably slower. More so on larger files. 1500ms vs 100ms for a 4GiB movie!

[jarun]

If it's slower let's just leave it. 2GB is common nowadays.

[0xACE]

@jarun are you frequently using git push -f?

The reason I'm asking is because there has been at least 10 seperate occurrences since I started using nnn where my copy of the repo diverges from origin/master.

Basically everytime I check github I usually pull changes from the repo and this is affecting me. I would like it to stop... I just came in to check on everything and continue my day but instead I'm dealing with a merge conflict.

this time I'm dealing with c4ae98a which is now listed as d8fe4b3

[KlzXS]

You could try something like git pull --rebase might suit you, might not. But this is just a workaround. Commits shouldn't just be changing hashes.

[jarun]

@0xACE that's correct. I prefer to keep changes grouped together to keep the history clean. So I keep rebasing which you are noticing.

The conflicts may be because of your local changes. Are you planning to make any changes soon? If not, how about rebasing only when you are going to make changes. I think the reason is you are having local changes. How about pushing your changes in a branch in your fork? That way your changes are always available to you and you can merge post each release.

Did you try rebasing or merging? When did you rebase last?

[jarun]

OK, I see. You did rebase in between 2 such changes. I will be more careful in future. However, do expect infrequent encounters. If we keep having separate commits for small changes tracking changes would become an issue. However, now I'll go for bigger commits to avoid this as much as possible.

[0xACE]

The conflicts aren't related to my changes.

At first it: my branch was just some small changes, but now it's a huge git stash, which i simplified by introducing another source file which contains the changes as functions or #define...

Currentlly I don't know what the best way to maintain my changes would be, but my next plan is to seperate that git stash into seperate commits of each change and remove that extra source file and always rebase on top of origin/master. But this won't happen until later this month (if I can find the time).

And really you can use your git repo as you like, I just wanted to let you know that git push -f has affected me several times in this repo. and luckily it hasn't been very difficult things to solve. Usually I may pull this repo 3-5 times a day, but for now maybe 1-2 per week...

I'm actually not a fan of github. but maybe I could could push a copy to github in the future

[jarun]

The conflicts aren't related to my changes.

In that case, just git pull --rebase.

[jarun]

Rolled at #329.