On 3/20/15, Abilio Marques <abili...@gmail.com> 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 <pault.eg...@gmail.com> wrote:
>
>> On 20/03/15 08:16, Peter Spjuth wrote:
>>
>>
>> On Fri, Mar 20, 2015 at 5:38 AM, Reimer Behrends <behre...@gmail.com>
>> 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
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
