The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,232 other followers

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

[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 »

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:

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.

Read the rest of this entry »

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.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:

  • [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 -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 as long_options and the Unix style options as short_options.
    The compatibility is maintained by preceding the long_options with two dashes

    Similar 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 »

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

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

jpluimers commented

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 true

This works splendid with git mergetool: it starts a merge in the already open BCompare.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 »

 
%d bloggers like this: