This project is mirrored from https://github.com/git/git. Pull mirroring updated .
  1. 20 Nov, 2005 2 commits
  2. 12 Nov, 2005 3 commits
  3. 08 Sep, 2005 1 commit
    • Junio C Hamano's avatar
      Big tool rename. · 215a7ad1
      Junio C Hamano authored
      As promised, this is the "big tool rename" patch.  The primary differences
      since 0.99.6 are:
      
        (1) git-*-script are no more.  The commands installed do not
            have any such suffix so users do not have to remember if
            something is implemented as a shell script or not.
      
        (2) Many command names with 'cache' in them are renamed with
            'index' if that is what they mean.
      
      There are backward compatibility symblic links so that you and
      Porcelains can keep using the old names, but the backward
      compatibility support  is expected to be removed in the near
      future.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      215a7ad1
  4. 30 Aug, 2005 1 commit
    • Linus Torvalds's avatar
      [PATCH] Make "git resolve" less scary · cdcb0ed4
      Linus Torvalds authored
      When we resolve a merge between two branches, and it removes a file in the
      current branch, we notify the person doing the resolve with a big nice
      notice like
      
      	Removing xyzzy
      
      which is all well and good.
      
      HOWEVER, we also do this when the file was actually removed in the current
      branch, and we're merging with another branch that didn't have it removed
      (or, indeed, if the other branch _did_ have it removed, but the common
      parent was far enough back that the file still existed in there).
      
      And that just doesn't make sense. In that case we're not removing
      anything: the file didn't exist in the branch we're merging into in the
      first place. So the message just makes people nervous, and makes no sense.
      
      This has been around forever, but I never bothered to do anything about
      it.
      
      Until now.
      
      The trivial fix is to only talk about removing files if the file existed
      in the branch we're merging into, but will not exist in the result.
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cdcb0ed4
  5. 30 Jul, 2005 1 commit
  6. 25 Jun, 2005 1 commit
    • Junio C Hamano's avatar
      [PATCH] git-merge-one-file-script: do not misinterpret rm failure. · aacc15ec
      Junio C Hamano authored
      When a merge adds a file DF and removes a directory there by
      deleting a path DF/DF, git-merge-one-file-script can be called
      for the removal of DF/DF when the path DF is already created by
      "git-read-tree -m -u".  When this happens, we get confused by a
      failure return from 'rm -f -- "$4"' (where $4 is DF/DF); finding
      file DF there the "rm -f" command complains that DF is not a
      directory.
      
      What we want to ensure is that there is no file DF/DF in this
      case. Avoid getting ourselves confused by first checking if
      there is a file, and only then try to remove it (and check for
      failure from the "rm" command).
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      aacc15ec
  7. 09 Jun, 2005 2 commits
    • Linus Torvalds's avatar
      One more time.. Clean up git-merge-one-file-script · 98a96b00
      Linus Torvalds authored
      This uses git-checkout-file to make sure that the full pathname is
      created, instead of the script having to verify it by hand.  Also,
      simplify the 3-way merge case by just writing to the right file and
      setting the initial index contents early.
      98a96b00
    • Linus Torvalds's avatar
      Fix up git-merge-one-file-script · e0226add
      Linus Torvalds authored
      Junio points out that we may need to create the path leading
      up the the file we merge.
      
      And we need to be more careful with the "exec"s we've done
      to exit on success - only do the on the last command in the
      pipeline, not the first one ;)
      e0226add
  8. 08 Jun, 2005 4 commits
  9. 07 May, 2005 1 commit
  10. 02 May, 2005 1 commit
  11. 01 May, 2005 1 commit
    • Junio C Hamano's avatar
      [PATCH] Really fix git-merge-one-file-script this time. · 21a08dcb
      Junio C Hamano authored
      The merge-cache program was updated to pass executable bits when
      calling git-merge-one-file-script, but the called script
      supplied as an example were not using them carefully.
      
      This patch fixes the following problems in the script:
      
       * When a new file is created in a directory, which is a file in
         the work tree, it tried to create leading directory but did
         not check for failure from the "mkdir -p" command.
      
       * The script did not check the exit status from the
         git-update-cache command at all.
      
       * The parameter "$4" to the script is a file name that can
         contain almost any characters, so it must be quoted with
         double quotes and also needs to be preceded with -- to mark
         it as a non-option when passed to certain commands.
      
       * The chmod command was used with parameter "$6" or "$7" to set
         the mode bits.  This contradicts with the strategy taken by
         checkout-cache, where we honor user's umask and force only
         the executable bits.  With this patch, it creates a new file
         by redirecting into it (thus honoring user's default umask),
         and then uses "chmod +x" if we want the resulting file
         executable.  Without this fix, the merge result becomes 0644
         or 0755 for users whose umask is 002 for whom it should
         become 0664 or 0775.
      
       * When "$1 -> $2 -> $3" case was not handled, the script did
         not say which path it was working on, which was not so useful
         when used with the -a option of git-merge-cache.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      Signed-off-by: default avatarLinus Torvalds <[email protected]>
      21a08dcb
  12. 29 Apr, 2005 2 commits
  13. 24 Apr, 2005 1 commit
  14. 19 Apr, 2005 1 commit
    • James Bottomley's avatar
      [PATCH] SCSI trees, merges and git status · 0a9ea850
      James Bottomley authored
      Doing the latest SCSI merge exposed two bugs in your merge script:
      
      1) It doesn't like a completely new directory (the misc tree contains a
         new drivers/scsi/lpfc)
      2) the merge testing logic is wrong.  You only want to exit 1 if the
         merge fails. 
      0a9ea850
  15. 18 Apr, 2005 2 commits
    • Linus Torvalds's avatar
      Change merge-cache and git-merge-one-file to use the SHA1 of the file · e3b4be7f
      Linus Torvalds authored
      instead of a checked-out temporary copy.
      
      If merging requires a checked-out-copy, we now do so with "unpack-file".
      e3b4be7f
    • Linus Torvalds's avatar
      Add the simple scripts I used to do a merge with content conflicts. · 839a7a06
      Linus Torvalds authored
      They sure as hell aren't perfect, but they allow you to do:
      
      	./git-pull-script {other-git-directory}
      
      to do the initial merge, and if that had content clashes, you do
      
      	merge-cache ./git-merge-one-file-script -a
      
      which tries to auto-merge. When/if the auto-merge fails, it will
      leave the last file in your working directory, and you can edit
      it and then when you're happy you can do "update-cache filename"
      on it. Re-do the merge-cache thing until there are no files left
      to be merged, and now you can write the tree and commit:
      
      	write-tree
      	commit-tree .... -p $(cat .git/HEAD) -p $(cat .git/MERGE_HEAD)
      
      and you're done.
      839a7a06