gistfile1.eclass

function changes {
  start="$1"
  end="$2"

  if [ -z "$2" ]; then
    start="$1"^
    end="$1"
  fi

  if [ -z "$1" ]; then
    start=HEAD^
    end=HEAD
  fi

  git diff --name-only $start..$end | sort | uniq
}

I don't know how to do the variable thing in Bash. I expect it to work like, you know... a programming language. Except I can't even guess at how variables work in Bash.

Look at the git project on git completion. I'm sure there are more than one. I have one that really helps prompting correctly for the next part of the git command I am using. In there will be lots of useful examples of bash variables. You might also try "local" in front of variable declaration.

Current version is what I ended up with

Couldn't figure out how gist works. . . so I'll just post my code inline:

changes()
{
    local start="${1:-HEAD}"
    local end="${2:-${start}}"
    git show --pretty="format:" --name-only "$start..$end" | sort | uniq
}

There's a number of things I'm illustrating in this commit.

1. use real POSIX-shell function syntax of "function_name() {}"
2. using the "local" keyword to avoid namespace bleeding
3. being mindful of quotes, which dodges shell pitfalls
4. using POSIX-shell default parameter expansion of "${NAME:-DEFAULT}".

Learning POSIX-compliant shell is a sometimes tedious, because the specification is kind of hidden away by The Open Group. I often end up looking at the Dash manpage , because Dash more or less targets POSIX specifically. Other shells like Bash and Korn layer tiers of functionality above and beyond the POSIX specification, which just makes for non-portable shell scripts. And furthermore, these extensions aren't worth it. They're great to help out users interactively, but they're generally not worth the tradeoff for portability. If you really need features beyond POSIX-compliant shell. . . just jump to Ruby. You're probably looking for things like real data structures. Messing around with things like Bash arrays is a waste.

okay, I realize I cleaned up the shell stuff. . . but goofed on the actual task at hand. . . I changed the semantics of the program entirely by not reading into the ^ stuff carefully. I'll post a fix in a moment.

I came to the conclusion that your if-then logic is readable relative to any fancy shell parameter expansion I can come up with (which I gave up on). I think you have what you need to figure it out now.

For future reference I recommend the Advance Bash Scripting Guide - PDF / HTML versions at http://tldp.org/guides.html