[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
Posted by jpluimers on 2020/12/31
[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
Posted in Development, DVCS - Distributed Version Control, git, GitHub, LifeHacker, Power User, Source Code Management | Leave a Comment »
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:
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.
Posted in Delphi, Development, PlasticSCM, Software Development, Source Code Management, Versioning | Leave a Comment »
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.txt
and 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:
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 checkout
1 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.
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 -z
will 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_options
and 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
Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »
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
Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »
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
x86
one)- do not want a new UI instance, so use the recommended
BComp.exe
git 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.exe
instance.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:
What I need to find out is if it is possible to open all merges at once in Beyond Compare. Maybe these help:
This did help getting rid of .orig
files: [WayBack] version control – Git mergetool generates unwanted .orig files – Stack Overflow
–jeroen
Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »
jpluimers commented