Re: [egit-dev] locking mechanism

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

----- Ursprungligt meddelande -----
> Från: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
> Till: "Robin Rosenberg" <robin.rosenberg@xxxxxxxxxx>, "Christian Halstrick" <christian.halstrick@xxxxxxxxx>
> Kopia: "EGit developer discussion" <egit-dev@xxxxxxxxxxx>
> Skickat: torsdag, 19 dec 2013 22:17:26
> Ämne: 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.

true. Many arguments for doing something one way is that we used to do it. The
proposed change *WILL* surprise people in a bad way. I you want to change, leave the
defaults with the current behavior and allow people to change it, not the
other way around.

> 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.

As one of the authors I'm speaking of why we implemented it this way, not why
I think others did it.

> 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.

I never (well rarely) just commit. Autostaging in delete/rename means I
have to make fewer adjustments in the normal case than without. Not doing
it for new files is because the workspace often constains crap that should
not be added. NOT for any other reason. git mv and git rm also autostages,
so there is no inconsistency in that sense.

-- robin

> 
> - 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
> 
>