I'll throw in my visualisation if it's any help. It (Staging) is like having the old style "Out" tray at the edge of you desk where the mail person will collect all the packages when everything is ready, as a nice tied up bundle.
It means you can prepare individual 'files' for the bundle and put them in the 'out' tray as you progress, and if needed get one file back for an update, then it's right there. You can update and change anything in that 'Out' tray bundle right up to the point that you set the 'collect the bundle (Commit!)' flag and the mail person whisks it off to the storage repository. If you have the tooling/head-model, then it's quite easy to 'add' each file as any part is completed (even just the update of a single function/section). The neat thing is that, being a computer, the house elfs have already taken a sneak copy of everything you place in the 'Out' box and put the copy in the Object store, so you have a simple 'backup' of all those small 'done' jobs. All that happens when you do that final 'commit' is that all the latest things in the object store/outbox are tied (bundled) with string/ribbon as the commit object (links to previous commit) and tree object (file object links). That is real quick as it doesn't need to touch the files at all (the job was done earlier). https://www.wisconsinhistory.org/Records/Image/IM97014 Office Clerks with IN/Out box. (see the desk clutter!) On Thursday, September 16, 2021 at 8:03:09 AM UTC+1 o...@ucm.es wrote: > > > Uwe Brauer <o...@mat.ucm.es> writes: > > > > Well, changes always have to be staged, but as you can see in the > > git-commit manpage there's an option to stage all changes to known > > files automatically by using > > > git commit -a > > Ah, very well. That indeed is helpful. > > > If you mean magit I have to say it's absolutely worth trying. It's > > what I use to do 99% of the times I need to do some "git stuff". > > > Well I meant even the simpler vc.el, but yes people often talk about > magit, at some point I must give it a try. > > > There you _also_ have to stage changes, but the interface is a bit > > more clear about it. > > > > Staging is a bit of a mind-shift, but I do urge you to give it an > > honest shot before condemning it. When I switched to git from > > svn/hg I found it to be an utterly weird idea. Just a completely > > useless nuisance. Over time I've found it's grown on me, and now I > > miss it whenever I have to do work in a VCS that doesn't have it. > > In particular I've found that it allows me to not "self-censor"; > > I'll make any changes I want in my workspace, even ones that > > aren't related to the issue I'm working on at the moment, because > > I know that I can split the changes into multiple commits later > > on. Staging is the mechanism that enables that. > > Right. I do not condem staging, not at all, it is only the idea of > «adding a file» that is already there seems contra intuitive. > > As for stagint (or similar concepts): it might be annoying if you just > want to commit a quick fix, but if you have already done some changes > and you want really to control what you are going to commit. > > In mercurial I sometimes committed changes I did not want to commit, > however with the new evolve extension you can commit interactively > changes you want, so that is very similar to staging and I use it a lot. > It is funny to see that git and hg at the end have very similar > functionality however using a different philosophy and that might > confuse users that switch from one to another. > > > Anyhow, thanks for your help > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/50677f51-115e-4b8d-92a5-7cd4ea5f9aedn%40googlegroups.com.
