[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] locking mechanism
|
> Good user interfaces are not "consistent", just like users arent'.
> They are easy to understand (even if you don't like it) and usually
> do what you want to do and when not, thet let you correct easily. The
> fact that some haven't even noticed EGit does this is a hint that
> the behavior can't be all bad.
While inconsistency is sometimes warranted, there should be a strong case for every consistency deviation as consistency of behavior is exactly how users learn interfaces.
As to auto-staging, the point of the explicit staging is to give the user more control over pulling out change lists out of the mass of local changes. Some like this aspect of Git, some hate it, but any auto-staging definitely interferes with the functionality of this feature. Consider the case where a delete or an add is not related to the change that you are presently composing in the staging view. Now I have to notice that EGit has helpfully staged a file behind my back. Hopefully I don't miss it before I commit the change.
- Konstantin
-----Original Message-----
From: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-bounces@xxxxxxxxxxx] On Behalf Of Robin Rosenberg
Sent: Thursday, December 19, 2013 1:02 PM
To: Christian Halstrick
Cc: EGit developer discussion
Subject: Re: [egit-dev] locking mechanism
----- Ursprungligt meddelande -----
> Från: "Christian Halstrick" <christian.halstrick@xxxxxxxxx>
> Till: "laurent goubet" <laurent.goubet@xxxxxxx>
> Kopia: "EGit developer discussion" <egit-dev@xxxxxxxxxxx>
> Skickat: torsdag, 19 dec 2013 10:57:37
> Ämne: Re: [egit-dev] locking mechanism
>
> On Thu, Dec 19, 2013 at 10:26 AM, Laurent Goubet
> <laurent.goubet@xxxxxxx>
> wrote:
> > 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)
>
> +1 . I also don't like that we handle deletions so much different than
> other modifications. (To be honest, I didn't even know we where
> doing). I would vote for staging deletions explicitly.
-1.
When I delete a file, I want to stage the deletion. It's very rare that I don't, in which case I can unstage in the staging view.
Why not auto-stage adds? Mostly because it would occasionally cause massive staging which is hard to undo.
Good user interfaces are not "consistent", just like users arent'. They are easy to understand (even if you don't like it) and usually do what you want to do and when not, thet let you correct easily. The fact that some haven't even noticed EGit does this is a hint that the behavior can't be all bad.
As for moves, JGit doesn't detect moves, unless it tracking both the old and new file.
The real reason is that we do what we do is the design of the Team API, that suggested the behavior.
-- robin
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
