[WayBack] Syncing your fork to the original repository via the browser · KirstieJane/STEMMRoleModels Wiki · GitHub
TL;DR: you can do the sync from the Web UI, but it always gives you an extra merge commit.
–jeroen
Archive for the ‘Source Code Management’ Category
Syncing your fork to the original repository via the browser · KirstieJane/STEMMRoleModels Wiki · GitHub
Posted by jpluimers on 2020/12/31
Posted in Development, DVCS - Distributed Version Control, git, GitHub, LifeHacker, Power User, Source Code Management | Leave a Comment »
PlasticSCM memories
Posted by jpluimers on 2020/12/23
Spending most of your career as an independent contractor, you bump into a lot of toolchains.
Part of those toolchains usually involved (and by now surely should involve) version control for both development and infrastructure configuration management.
I remember PlasticSCM quite well.
The really good part is the branch overview (called Branch Explorer) in the PlasticSCM UI, as it is:
- horizontal, which makes it far easier to walk branches over time (as screens tend to have more horizontal space than vertical, and the interesting branches tend to live longer than boring ones), a good example of the difference is at [WayBack] Gamasutra: Matt Schoen’s Blog – I Gave PlasticSCM a Try of which I included screenshots further below.
- highly configurable (filtering, colouring most things including branch, commit-icon parts, etc):
“Tip of the day: color your Branch Explorer based on the status of branches”[WayBack] Plastic SCM on Twitter: “Tip of the day: color your Branch Explorer based on the status of branches… “
- the arrows pointing from a commit to the source commits, which makes it more intuitive to find where stuff comes from:
[WayBack] Plastic SCM vs Git – Pablo Santos Luaces – Medium (note that merging in git does not force you to loose the branche: that’s a choice you make while merging)
They also have frequent updates, which however are hard to discover because there is no built-in update mechanism that notifies you of them.
Those updates are badly needed, because I kept bumping into bugs. Which is odd, because I bumped into far less issues when using UI layers for SVN, TFS, Mercurial and git (SourceTree being a major exception, but they seem to have recovered from a long period of bad versions a few years back).
So here are some of my gripes, that might have been fixed by now.
Share this:
Posted in Delphi, Development, PlasticSCM, Software Development, Source Code Management, Versioning | Leave a Comment »
git the meaning of `–` is to treat the rest of the arguments as file names (Hard reset of a single file – Stack Overflow)
Posted by jpluimers on 2020/12/16
Learned TWO things at once Mark Longair and VonC at [WayBack] git – Hard reset of a single file – Stack Overflow :
You can use the following command:
git checkout HEAD -- my-file.txt… which will update both the working copy of
my-file.txtand its state in the index with that from HEAD.
--basically means: treat every argument after this point as a file name. More details in this answer. Thanks to VonC for pointing this out.
Related:
- [WayBack] User Mark Longair – Stack Overflow
- [WayBack] User VonC – Stack Overflow
- [WayBack] User zwol – Stack Overflow
- [WayBack] Difference between “git checkout ” and “git checkout -- ” – Stack Overflow
The special “option”
--means “treat every argument after this point as a file name, no matter what it looks like.” This is not Git-specific, it’s a general Unix command line convention. Normally you use it to clarify that an argument is a file name rather than an option, e.g.rm -f # does nothing rm -- -f # deletes a file named "-f"git checkout1 also takes--to mean that subsequent arguments are not its optional “treeish” parameter specifying which commit you want.So in this context it’s safe to use
--always, but you need it when the file you want to revert has a name that begins with-, or is the same as the name of a branch. Some examples for branch/file disambiguation:git checkout README # would normally discard uncommitted changes # to the _file_ "README" git checkout master # would normally switch the working copy to # the _branch_ "master" git checkout -- master # discard uncommitted changes to the _file_ "master"and option/file disambiguation:
git checkout -p -- README # interactively discard uncommitted changes # to the file "README" git checkout -- -p README # unconditionally discard all uncommitted # changes to the files "-p" and "README"I’m not sure what you do if you have a branch whose name begins with
-. Perhaps don’t do that in the first place.
1 in this mode; “checkout” can do several other things as well. I have never understood why git chose to implement “discard uncommitted changes” as a mode of the “checkout” subcommand, rather than “revert” like most other VCSes, or “reset” which I think might make more sense in git’s own terms.
- [WayBack] Deleting a badly named git branch – Stack Overflow
Did you try
git branch -D -- --track? the “
--” is usually the convention for “what follows is not an option, whatever its name”
From “The Art of Unix Programming“, section “Command-Line Options“:
It is also conventional to recognize a double hyphen as a signal to stop option interpretation and treat all following arguments literally.
You will find that convention in other (not necessary Unix-related) CLI (Command Line Interface) like cleartool:
If a nonoption argument begins with a hyphen (
–) character, you may need to precede it with a double-hyphen argument, to prevent it from being interpreted as an option:cleartool rmtype -lbtype -- -temporary_label-The P18 (a fast and flexible file preprocessor with macro processing capabilities and special support for internationalization) mentions that also and gives a good description of the general idea behind that convention:
All option arguments passed to the commands start with a single hyphen.
All option arguments (if any) must precede all non-option arguments.
The end of the option arguments may be signaled using a double hyphen, this is useful if a non-option argument starts with a hyphen. Terminating the list of option arguments with a double hyphen works for all commands, even those that don’t take any option arguments.The OptionParser tool written in ruby also lays it out quite plainly:*
Option Parsing Termination
It is convention that a double hyphen is a signal to stop option interpretation and to read the remaining statements on the command line literally. So, a command such as:
app -- -x -y -zwill not ‘see’ the three mode-flags. Instead, they will be treated as arguments to the application:
#args = ["-x", "-y", "-z"]
Note: sometimes, it takes three dashes and not two, especially when the CLI follows strictly the Gnu options styles:
The Gnu style command line options provide support for option words (or keywords), yet still maintain compatibility with the Unix style options.
The options in this style are sometimes referred to aslong_optionsand the Unix style options asshort_options.
The compatibility is maintained by preceding the long_options with two dashesSimilar to the Unix style double-hyphen ’
--’, the Gnu style has a triple-hyphen ’---’ to signal that option parsing be halted and to treat the remaining text as arguments (that is, read literally from the command line)So… if ‘
--‘ is not enough (it should be with Git commands), try ‘---‘
–jeroen
Share this:
Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »
How to have git log show filenames like svn log -v – Stack Overflow
Posted by jpluimers on 2020/12/01
I stick to git log --name-status as suggested in [WayBack] How to have git log show filenames like svn log -v – Stack Overflow.
A slightly less readable alternative isgit log --num-status .
There is also git log --name-only as suggested in [WayBack] How to show changed file name only with git log? – Stack Overflow
–jeroen
Share this:
Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »
Git Mergetool and difftool with Beyond Compare 4 · GitHub
Posted by jpluimers on 2020/11/26
For my archive: [WayBack] Git Mergetool and difftool with Beyond Compare 4 · GitHub
I stuck to this as I:
- do not run
git bash- have Beyond Compared installed in the default directory (not the
x86one)- do not want a new UI instance, so use the recommended
BComp.exegit config --global merge.tool bc4 git config --global mergetool.bc4.cmd "'C:/Program Files/Beyond Compare 4/BComp.exe' \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"" git config --global mergetool.bc4.trustExitCode trueThis works splendid with
git mergetool: it starts a merge in the already openBCompare.exeinstance.I only do merge from Beyond Compare, so no need for me to do a similar Beyond Compare setup for
diff.tool, but if anyone wants it, it would be this:git config --global diff.tool bc4 git config --global difftool.bc4.cmd "'C:/Program Files/Beyond Compare 4/BComp.exe' \"$LOCAL\" \"$REMOTE\"" git config --global difftool.bc4.prompt false
This works fine for any git versoin > 2.2.0.
Related:
- [WayBack] Beyond Compare Technical Support: git for Linux
- [WayBack] Integrate beyond compare 4 with git · GitHub
- [WayBack] Beyond Compare Technical Support: git for Windows
- [WayBack] Git – git-merge Documentation
- [WayBack] Git – git-mergetool Documentation
- [WayBack] How the git mergetool solved my anxiety, fears, and most importantly, my merge conflicts | Knight Lab
What I need to find out is if it is possible to open all merges at once in Beyond Compare. Maybe these help:
- [WayBack] How do I make gvimdiff opened by git mergetool open all files at once in tabs? – Stack Overflow
- [WayBack] git difftool, open all diff files immediately, not in serial – Stack Overflow
This did help getting rid of .orig files: [WayBack] version control – Git mergetool generates unwanted .orig files – Stack Overflow
–jeroen
Share this:
Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »
jpluimers commented