Yeah, stash is the way I do all the time, but sometimes I want to exclude binaries that are regenerated each time a change and compilation occurs, until I'm ready to the new version to go into trunk.
Top of my mind, the PDF files that are generated when I use LaTeX. I want to keep the stable version in trunk, yet avoid including binaries that are sometimes hundreds of Kbytes each commit to my "this is just a test" branch, or "this is a modification in progress" branch. I would have to stash the PDFs before each commit (and they are not useful anyway) or type down the entire list of files that I want to include on each commit, which are different each time. But by doung fossil ci --ignore file1.pdf file2.pdf -m "here is an example", I can reuse that command 15 times without using the brain harder than a normal "complete" commit will ask me for, until I'm ready to go to the trunk. On Fri, Mar 20, 2015 at 2:25 PM, Richard Hipp <[email protected]> wrote: > On 3/20/15, Abilio Marques <[email protected]> wrote: > > But sometimes the subset of files to include in the first commit is > longest > > than the ones to be included in the second... so perhaps something like > > > > fossil ci -m "first commit" --ignore file1 file2 > > I have your request. In the meantime, consider this work-around: > > fossil stash save file1 file2 > # test > fossil ci -m "first commit" > fossil stash pop > > > > > would be easier than: > > fossil ci -m "first commit" file3 file4 file5 file6... file12 > > > > > > On Fri, Mar 20, 2015 at 2:13 PM, paul <[email protected]> wrote: > > > >> On 20/03/15 08:16, Peter Spjuth wrote: > >> > >> > >> On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends <[email protected]> > >> wrote: > >> > >>> First, the safer (and arguably overall better) approach is to recognize > >>> that stash/shelve operations are the inverse of the staging area for > >>> this > >>> purpose. I.e., rather than stage a partial commit, you stash everything > >>> but > >>> the partial commit, then commit whatever changes remain in toto. This > >>> does > >>> not require the staging area and ensures that, e.g., you're not > >>> committing > >>> something that doesn't even compile (which breaks bisect, CI tools, > >>> etc.). > >>> > >> > >> This is exactly my viewpoint. A work a lot in Subversion and I often > miss > >> a stash, never a staging area. > >> I have used git's staging area as intended occasionally but mostly I > find > >> it annoying. I feel slighty dirty > >> when I do a partial commit since I know it is, in theory at least, > >> untested. > >> > >> A stash with abilites like "git add --interactive" to stash parts within > >> a > >> file is the way to go IMO. > >> > >> /Peter > >> > >> > >> > >> > >> When I was using git and came to fossil I missed the staging area. > >> Sometimes > >> when making a change I'd want to make a change to another part of the > >> software > >> to support the change I was making, and so then ended up doing two > >> commits. > >> > >> The reason I liked the staging area was because before committing I'd > >> always > >> do diff/add/status, to review changes, and have one final check that > >> everthing > >> was OK before actually committing. > >> > >> Then I would add the remaining files and do the next commit. > >> > >> But as fossil can commit a subset of changes, I can still manage to do > >> what I > >> like. > >> > >> > >> > >> _______________________________________________ > >> fossil-users mailing list > >> [email protected] > >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >> > >> > > > > > -- > D. Richard Hipp > [email protected] > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
