Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] locking mechanism

On Thu, Dec 19, 2013 at 10:26 AM, Laurent Goubet <laurent.goubet@xxxxxxx> wrote:

On 19/12/2013 09:48, Gunnar Wagenknecht wrote:
Am 18.12.2013 um 16:06 schrieb Lay, Stefan <stefan.lay@xxxxxxx>:
 I also don't understand why deletions are automatically added to the index. Maybe this was necessary at the very beginning of the Egit/Jgit project. I would rather remove it for the deletion of files than add it for adding files.

It definitely was a usability issue in the beginning. Deleting a file should be simple. If I delete a file in my workspace and then commit, the delete must be committed. We should not require the user to perform any additional operation.


I usually try and think "for the user" ... but here I do not see that hook as an usability improvement. Rather, it introduces one "magical" thing in git where everything else is not.

I create a new file? I need to use Team > Add in order to stage its addition. This is the same behavior as the command line. (touch file1.txt , then git add file1.txt)
I change a file? I need to use Team > Add in order to stage the change. This is the same behavior ... (vi file1.txt ... changes... save... git add file1.txt)
I fix a conflict in a file during a rebase? I need to use Team > Add... same behavior as command line.

I delete file? Well this time the Team > Add has been done magically. This is not the same behavior as the command line. (rm file1.txt, git rm file1.txt)

I think this actually disrupts the git workflows.

I think we should remove this auto-staging of deletions 
Having said that, I think the delete hook can be removed *if* we can ensure that the deleted file is pre-selected in the commit dialog when I invoke it on any of it’s parents (parent folder or project). Back in the days this wasn’t the case.

We do not "totally" agree here. The commit dialog is also something I find disturbing as a git user : on the one hand, I like the fact that it autoselects things to commit, and I agree on the fact that deletions should also be autoselected.

On the other hand, I hate the fact that this commit dialog totally ignores what I have staged.

If I took the time to stage (git add and git rm) things to my commit, I'd like EGit to understand that in the commit dialog (it already does so in the staging view, but I do not always use the staging view) and autoselections to be disabled in favor on what's already in the index. If I have staged nothing, then auto-selections could be activated.

I don't use the commit dialog anymore since a long time, do we still need a second way to commit
behaving differently and non-git-ish ? We could simply delete the CommitDialog and open
the staging view when a user clicks "Commit..." 

 
But I don’t know about moves. Doesn’t JGit auto-detect moves?
git and also jgit do a similarity check on the content to decide if a combination
of a file deletion and a file addition in the same commit is to be considered as a move.

If we don't auto-stage a move it may happen that the user misses to stage 
both the deletion of the old path and the addition of the new path for the same
commit which could lead to a split move spread across multiple commits.

--
Matthias

Back to the top