Re: [egit-dev] locking mechanism

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

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