1. 23 Aug, 2017 1 commit
  2. 10 May, 2017 1 commit
    • Johannes Schindelin's avatar
      Fix build with core.autocrlf=true · 00ddc9d1
      Johannes Schindelin authored
      On Windows, the default line endings are denoted by a Carriage Return
      byte followed by a Line Feed byte, while Linux and MacOSX use a single
      Line Feed byte to denote a line ending.
      To help with this situation, Git introduced several mechanisms over the
      last decade, most prominently the `core.autocrlf` setting.
      Sometimes, however, a single setting is incorrect, e.g. when certain
      files in the source code are to be consumed by software that can handle
      only LF line endings, while other files can use whatever is appropriate
      for the current platform.
      To allow for that, Git added the `eol` option to its .gitattributes
      handling, expecting every user of Git to mark their source code
      Bash assumes that line-endings of scripts are denoted by a single Line
      Feed byte. Therefore, shell scripts in Git's source code are one example
      where that `eol=lf` option is *required*.
      When generating common-cmds.h, the Unix tools we use generally operate on
      the assumption that input and output deliminate their lines using LF-only
      line endings. Consequently, they would happily copy the CR byte verbatim
      into the strings in common-cmds.h, which in turn makes the C preprocessor
      barf (that interprets them as MacOS-style line endings). Therefore, we
      have to mark the input files as LF-only: command-list.txt and
      Quite a bit belatedly, this patch brings Git's own source code in line
      with those expectations by setting those attributes to allow for a
      correct build even when core.autocrlf=true.
      This patch can be validated even on Linux, by using this cadence:
      	git config core.autocrlf true
      	rm .git/index && git stash
      	make -j15 DEVELOPER=1
      Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <johannes.schindelin@gmx.de>
      Reviewed-by: 's avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  3. 27 Dec, 2015 1 commit
  4. 07 Jun, 2007 1 commit
    • Junio C Hamano's avatar
      War on whitespace · a6080a0a
      Junio C Hamano authored
      This uses "git-apply --whitespace=strip" to fix whitespace errors that have
      crept in to our source files over time.  There are a few files that need
      to have trailing whitespaces (most notably, test vectors).  The results
      still passes the test, and build result in Documentation/ area is unchanged.
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  5. 21 Jan, 2007 10 commits
    • Shawn O. Pearce's avatar
      git-gui: Modified makefile to embed version into git-gui script. · 41bdcda3
      Shawn O. Pearce authored
      We want to embed the version of git-gui directly into the script file,
      so that we can display it properly in the about dialog.  Consequently
      I've refactored the Makefile process to act like the one in core git.git
      with regards to shell scripts, allowing git-gui to be constructed by a
      sed replacement performed on git-gui.sh.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Hide the ugly bash command line from the windows desktop icon. · c2562332
      Shawn O. Pearce authored
      The user really doesn't need to see the technical details of how we
      launch git-gui from within their "desktop icon".  Instead we should hide
      the command line from being displayed when the icon launches by putting
      @ at the start of the line.  If they really need to see the command we
      are running they can edit the batch file.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Change more 'include' language to 'add'. · 4d583c86
      Shawn O. Pearce authored
      I just found a whole slew of places where we still were using the term
      'include' rather than 'add' to refer to the act of updating the index
      with modifications from the working directory.  To be consistent with
      all Git documentation and command line tools, these should be 'add'.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Work around odd cygpath bug on Windows. · bdadecba
      Shawn O. Pearce authored
      There appears to be a bug on one of my test systems where cygpath with
      the --long-name option is generating a corrupt string that does not
      actually refer to sh.exe.  This breaks any desktop icon created by
      git-gui as the executable we are trying to invoke does not exist.
      Since Cygwin is typically installed as C:\cygwin long path names is
      probably not actually necessary to link to the shell.
      I also added a small echo to the start of the icon script, as it can
      take one of my test systems several seconds to startup git-gui.  This
      way the user knows we're starting git-gui, and was politely asked to
      wait for the action to complete.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Correct wording of the revert confirmation dialog. · 68cbfb13
      Shawn O. Pearce authored
      We no longer describe updating the index as including changes, as we
      now use the add notation used by core Git's command line tools.  So
      its confusing to be talking about unincluded changes within the revert
      dialog.  Instead we should used language like 'unadded changes'.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Corrected behavior of deleted (but existing in HEAD) files. · 6b0f3f46
      Shawn O. Pearce authored
      Apparently I did not account for the D_ file state.  This can occur when
      a file has been marked for deletion by deleting it from the index, and
      the file also does not exist in the working directory.  Typically this
      happens when the user deletes the file, hits Rescan, then includes the
      missing file in the commit, then hits Rescan again.  We don't find the
      file in the working directory but its been removed in the index, so the
      state becomes D_.
      This state should be identical with DD.  I'm not entirely sure why DD
      occurs sometimes and D_ others, it would seem like D_ is the state that
      should be happening instead of DD, leading me to believe there is a quirk
      in git-gui's state manipulation code.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Run git-gc rather than git-repack. · 81c0f29a
      Shawn O. Pearce authored
      Now that git 1.5.0-rc1 and later has a 'git gc' command which performs
      all important repository management activites (including reflog pruning,
      repacking local objects, unnecessary loose object pruning and rerere cache
      expiration) we should run 'gc' when the user wants us to cleanup their
      object database for them.
      I think the name 'gc' is horrible for a GUI application like git-gui,
      so I'm labeling the menu action 'Compress Database' instead.  Hopefully
      this will provide some clue to the user about what the action does.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Show all fetched branches for remote pulls. · 51e7e568
      Shawn O. Pearce authored
      Loop through every remote.<name>.fetch entry and add it as a valid
      option in the Pull menu.  This way users can pull any remote branch
      that they track, without needing to leave the gui.  Its a rather crude
      work around for not having a full merge interface.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Created very crude Tools menu, to support miga. · 557afe82
      Shawn O. Pearce authored
      In one particular case I have a tool called 'miga' which users may need
      to invoke on their repository.  This is a homegrown tool which is not
      (and should be) part of git-gui, but I still want to be able to run it
      from within the gui.
      Right now I'm taking a shortcut and adding it to the Tools menu if
      we are not on Mac OS X and the support script used to launch the tool
      exists in the local filesystem.  This is nothing but a complete and
      utter hack.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Reworded 'Include' to 'Add' to match core Git. · eae2ce61
      Shawn O. Pearce authored
      Now that git-add is a first class citizen in core Git (Nico's 366bfcb6)
      users may start to expect the term 'add' to refer to the act of including
      a file's changes into a commit.  So I'm replacing all uses of the term
      'Include' in the UI with 'Add'.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
  6. 27 Nov, 2006 2 commits
    • Shawn O. Pearce's avatar
      git-gui: Auto-update any A? or M? files during rescan. · c15ad650
      Shawn O. Pearce authored
      If the user has partial includes disabled then it doesn't matter what
      state the working directory is in; if the file has been included in
      the next commit its index state is A or M and we should immediately
      run update-index on the working directory file to bring the index in
      sync with the working directory.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Enable resolution of merge conflicts. · f70c3a2c
      Shawn O. Pearce authored
      If a file has a merge conflict (index state = U) the user will need to
      run update-index on that file to resolve all stages down to stage 0,
      by including the file in the working directory.
      Like core Git we'll just trust the user that their resolution is
      correct, and that they didn't just include the file into the commit
      while merge conflicts still exist within the file.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
  7. 26 Nov, 2006 1 commit
  8. 25 Nov, 2006 6 commits
  9. 24 Nov, 2006 4 commits
  10. 23 Nov, 2006 1 commit
  11. 22 Nov, 2006 3 commits
  12. 21 Nov, 2006 9 commits
    • Shawn O. Pearce's avatar
      git-gui: Warn Cygwin users about possible environment issues. · 1d8b3cbf
      Shawn O. Pearce authored
      Because the Tcl binary distributed with Cygwin tends to not pass along
      its own environment (the env array) to its children, its unlikely that
      any Git commands spawned by git-gui will receive the same environment
      variables that git-gui itself received from the shell which started it.
      If the user is counting on environment variables to pass down, like say
      GIT_INDEX_FILE, they may not, so we warn them during git-gui startup
      that things may not work out as the user intended.  Perhaps one day
      when git-gui and git are running on native Windows (rather than through
      the Cygwin emulation layers) things will work better.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Correct is_MacOSX platform test. · 3add5d35
      Shawn O. Pearce authored
      Darwn based UNIX systems are not necessarily Mac OS X.  However the only
      windowing system used by Tk that is Mac OS X is 'aqua', and only 'aqua'
      exists on Mac OS X.  Therefore this is a more reliable test for the
      Macintosh platform.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Abstract out windows platform test to is_Windows proc. · 7b85a17b
      Shawn O. Pearce authored
      Like the is_MacOSX proc we shouldn't keep repeating the platform test
      for Windows.  Instead abstract the code out into a procedure and use
      the procedure whenever we need to do something special.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Include the Tcl/Tk version in the about dialog. · 53f7a33b
      Shawn O. Pearce authored
      Users may need to know what version of Tcl they are running git-gui
      under, in case there is an interesting interface quirk or other
      compatability problem we don't know about right now that we may
      need to explore (and maybe fix).  Since its simple enough to show
      a line with this version data we should do so.
      We also try to reduce the amount of text shown as often the Tcl and Tk
      version numbers will be identical; when this happens we should only show
      the one version number.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Make the copyright notice serve double duty. · bdc9ea20
      Shawn O. Pearce authored
      The copyright notice we display in the about dialog should be the same
      as the one at the top of our source code.  By putting the copyright
      notice that appears at the top of our source code into a global variable
      rather than a comment we can trivially make them the same at all times.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Be more Macintosh like. · 0c8d7839
      Shawn O. Pearce authored
      It is tradition for applications to store their about and preferences
      menu options within the application menu.  This is the first menu in
      the menu bar, just after the apple menu.  Apparently the way to access
      this menu from Tk on Mac OS X systems is to create a special menu whose
      name ends in ".apple" and place it into the menu bar.
      So now if we are on Mac OS X we move our about menu and our options menu
      into the application menu, like other Mac OS X applications.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Added about dialog box. · 82aa2354
      Shawn O. Pearce authored
      Created a help menu with an about dialog box.  This about dialog
      shows the copyright notice for the application, the fact that it
      is covered by the GPL v2.0 or later, the authors, and the current
      version of Git it is invoking when users perform actions within it.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Rename Project menu to Repository. · a4abfa62
      Shawn O. Pearce authored
      Since all of the actions in our Project menu actually apply to the
      Git concept of a repository, it is a disservice to our users to
      call it "project".  This is especially true if Git ever gets any
      sort of subproject support, as the term would then most definately
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>
    • Shawn O. Pearce's avatar
      git-gui: Seperate out the database operations in project menu. · 75e355d6
      Shawn O. Pearce authored
      The project menu is just too cluttered without using separator entries
      to split out the database operations (such as repack and verify) from
      the other options in the same menu.
      Signed-off-by: 's avatarShawn O. Pearce <spearce@spearce.org>