user/sven/git.git/lib/diff.tcl, branch gitgui-0.11.0

git-gui: Preserve scroll position on reshow_diff.

2008-07-27T15:08:10Z

It is especially useful for Stage/Unstage Line, because they invoke full state scan and diff reload, which originally would reset the scroll position to the top of the file. Signed-off-by: Alexander Gavrilov Signed-off-by: Shawn O. Pearce

git-gui: "Stage Line": Treat independent changes in adjacent lines better

2008-07-26T23:43:08Z

Assume that we want to commit these states: Old state == HEAD Intermediate state New state -------------------------------------------------------- context before context before context before old 1 new 1 new 1 old 2 old 2 new 2 context after context after context after that is, want to commit two changes in this order: 1. transform "old 1" into "new 1" 2. transform "old 2" into "new 2" [This discussion and this patch is about this very case and one other case as outlined below; any other intermediate states that one could imagine are not affected by this patch.] Now assume further, that we have not staged and commited anything, but we have already changed the working file to the new state. Then we will see this hunk in the "Unstaged Changes": @@ -1,4 +1,4 @@ context before -old 1 -old 2 +new 1 +new 2 context after The obvious way to stage the intermediate state is to apply "Stage This Line" to "-old 1" and "+new 1". Unfortunately, this resulted in this intermediate state: context before old 2 new 1 context after which is not what we wanted. In fact, it was impossible to stage the intermediate state using "Stage Line". The crux was that if a "+" line was staged, then the "-" lines were converted to context lines and arranged *before* the "+" line in the forged hunk that we fed to 'git apply'. With this patch we now treat "+" lines that are staged differently. In particular, the "-" lines before the "+" block are moved *after* the staged "+" line. Now it is possible to get the correct intermediate state by staging "-old 1" and "+new 1". Problem solved. But there is a catch. Noticing that we didn't get the right intermediate state by staging "-old 1" and "+new 1", we could have had the idea to stage the complete hunk and to *unstage* "-old 2" and "+new 2". But... the result is the same. The reason is that there is the exact symmetric problem with unstaging the last "-" and "+" line that are in adjacent blocks of "-" and "+" lines. This patch does *not* change the way in which "-" lines are *unstaged*. Why? Because if we did (i.e. move "+" lines before the "-" line after converting them to context lines), then it would be impossible to stage this intermediate state: context before old 1 new 2 context after that is, it would be impossible to stage the two independet changes in the opposite order. Let's look at this case a bit further: The obvious way to get this intermediate state would be to apply "Stage This Line" to "-old 2" and "+new 2". Before this patch, this worked as expected. With this patch, it does not work as expected, but it can still be achieved by first staging the entire hunk, then *unstaging* "-old 1" and "+new 1". In summary, this patch makes a common case possible, at the expense that a less common case is made more complicated for the user. Signed-off-by: Johannes Sixt Signed-off-by: Shawn O. Pearce

git-gui: Fix "Stage/Unstage Line" with one line of context.

2008-07-26T23:43:08Z

To "Stage/Unstage Line" we construct a patch that contains exactly one change (either addition or removal); the hunk header was forged by counting the old side and adjusting the count by +/-1 for the new side. But when we counted the context we never counted the changed line itself. If the hunk had only one removal line and one line of context, like this: @@ -1,3 +1,2 @@ context 1 -removal context 2 We had constructed this patch: @@ -1,2 +1,1 @@ context 1 -removal context 2 which does not apply because git apply deduces that it must apply at the end of the file. ("context 2" is considered garbage and ignored.) The fix is that removal lines must be counted towards the context of the old side. Signed-off-by: Johannes Sixt Signed-off-by: Shawn O. Pearce

git-gui: Implement "Stage/Unstage Line"

2008-07-02T05:06:38Z

This adds a context menu entry below "Stage/Unstage Hunk" that stages or unstages just the line under the mouse pointer. This is by itself useful, for example, if there are unrelated changes in the same hunk and the hunk cannot be split by reducing the context. The feature can also be used to split a hunk by staging a number of additions (or unstaging a number of removals) until there are enough context lines that the hunk gets split. The implementation reads the complete hunk that the line lives in, and constructs a new hunk by picking existing context lines, removing unneeded change lines and transforming other change lines to context lines. The resulting hunk is fed through 'git apply' just like in the "Stage/Unstage Hunk" case. Signed-off-by: Johannes Sixt Signed-off-by: Shawn O. Pearce

git-gui: Refresh file status description after hunk application

2008-01-16T06:29:39Z

If we apply a hunk in either direction this may change the file's status. For example if a file is completely unstaged, and has at least two hunks in it and the user stages one hunk the file will change from "Modified, not staged" to "Portions staged for commit". Resetting the file path causes our trace on this variable to fire; that trace is used to update the file header in the diff viewer to the file's current status. Noticed by Johannes Sixt. Signed-off-by: Shawn O. Pearce

git-gui: Handle file mode changes (644->755) in diff viewer

2007-12-14T06:51:22Z

Johannes Sixt pointed out the diff headers "old mode ..." and "new mode ..." were not being parsed properly by git-gui. We now include them in the diff viewer for a file. Signed-off-by: Shawn O. Pearce

git-gui: Paper bag fix missing translated strings

2007-09-14T05:51:18Z

The Tcl expression "[append [mc Foo] Bar]" does not return the string "FooBar" after translation; instead it is setting the variable Foo to the value Bar, or if Foo is already defined it is appending Bar onto the end of it. This is *not* what we wanted to have happen here. Tcl's join function is actually the correct function but its default joinStr argument is a single space. Unfortunately all of our call sites do not want an extra space added to their string. So we need a small wrapper function to make the call to join with an empty join string. In C this is (roughly) the job of the strcat function. Since strcat is not yet used at the global level it is a reasonable name to use here. Signed-off-by: Shawn O. Pearce

git-gui: add some strings to translation

2007-09-14T00:43:26Z

Most of these changes were suggested by Shawn Pearce in an answer to Johannes Schindelin. Some strings for the blame module were added too. [sp: Minor edits in blame module formatting] Signed-off-by: Michele Ballabio Signed-off-by: Shawn O. Pearce

Merge branch 'maint'

2007-09-10T01:02:57Z

* maint: git-gui: Trim trailing slashes from untracked submodule names git-gui: Assume untracked directories are Git submodules git-gui: handle "deleted symlink" diff marker git-gui: show unstaged symlinks in diff viewer

git-gui: Assume untracked directories are Git submodules

2007-09-10T00:39:42Z

If `git ls-files --others` returned us the name of a directory then it is because Git has decided that this directory itself contains a valid Git repository and its files shouldn't be listed as untracked for this repository. In such a case we should label the object as a Git repository and not just as a directory. Signed-off-by: Shawn O. Pearce