Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

* Joel Bruick [20140606 06:55]: > Richard Hipp wrote: > >On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams >> wrote: > > > >On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland >> wrote: > >> foo.txt has changes A, B, C and D. > >> >

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Fri, Jun 6, 2014 at 10:51 PM, Nico Williams wrote: > On Saturday, June 7, 2014, Andy Bradford < > amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org> wrote: > >> Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: >> >> > I should add that it's not always possible or desirable

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

Hey Nico -- Some thought-provoking comments. Thanks. -bch On 6/7/14, Gour wrote: > Nico Williams writes: > >> I wouldn't, don't, and won't demand that anyone follow such a workflow >> for >> any codebase I don't own, and possibly not for codebases I own either >> (depends). I only want to be

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

Nico Williams writes: > I wouldn't, don't, and won't demand that anyone follow such a workflow for > any codebase I don't own, and possibly not for codebases I own either > (depends). I only want to be able to do it myself easily when working > on codebases where i have to or want to. You pu

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Saturday, June 7, 2014, Andy Bradford < amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org> wrote: > Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: > > > I should add that it's not always possible or desirable to test all > > commits in a bundle that will be pushed togeth

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: > I should add that it's not always possible or desirable to test all > commits in a bundle that will be pushed together. A goal of breaking > up large commits into smaller ones is to make it easier to understand > and backport them

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Fri, Jun 6, 2014 at 7:45 PM, Nico Williams wrote: > I should add that it's not always possible or desirable to test all > commits in a bundle that will be pushed together. A goal of breaking > up large commits into smaller ones is to make it easier to understand > and backport them, but an en

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. Also

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

Richard Hipp wrote: On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams > wrote: On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland mailto:estifo...@gmail.com>> wrote: > foo.txt has changes A, B, C and D. > > After each change the developer had the foresight to

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo wrote: > I'm not Nico, but allow me answer that as well. > > When I was learning to use git, my teacher told me: > "When you have a set of changes where a peace of code requires another > peace, you must commit all that together. But if

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

I'm not Nico, but allow me answer that as well. When I was learning to use git, my teacher told me: "When you have a set of changes where a peace of code requires another peace, you must commit all that together. But if you have a change that doesn't have any dependeces, you should commit that cha

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Thu, Jun 5, 2014 at 7:58 PM, Richard Hipp wrote: > On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams wrote: >> >> On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland wrote: >> > foo.txt has changes A, B, C and D. >> > >> > After each change the developer had the foresight to do a "fossil stash >> > snap

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Thu, Jun 5, 2014 at 8:33 PM, Nico Williams wrote: > On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland wrote: > > foo.txt has changes A, B, C and D. > > > > After each change the developer had the foresight to do a "fossil stash > > snapshot". Now the developer decides to put changes B and D into b

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Thu, Jun 5, 2014 at 7:22 PM, Matt Welland wrote: > foo.txt has changes A, B, C and D. > > After each change the developer had the foresight to do a "fossil stash > snapshot". Now the developer decides to put changes B and D into branch b-d > and keep changes A and C on the trunk: Ah, foresight

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

Using stash and doing update then commits to appropriate branches along mostly addresses the need to split out changes from a single editing session. The one thing it cannot do is easily accommodate a mix of changes in a single file. That said I think I disagree that this is really needed. In git i

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Thu, Jun 5, 2014 at 10:36 AM, B Harder wrote: > drh> Fossil allows you to commit a subset of files (by listing the > files on the "fossil commit" command line) but there is no mechanism > for committing a subset of lines within a single file. > > That, and there _are_ branches/tags which are en

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

drh> Fossil allows you to commit a subset of files (by listing the files on the "fossil commit" command line) but there is no mechanism for committing a subset of lines within a single file. That, and there _are_ branches/tags which are encouraged to be used... my prev comment was for the case whe

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wed, Jun 4, 2014 at 11:08 PM, Alysson Gonçalves de Azevedo < agalys...@gmail.com> wrote: > I started to use fossil just today, but let me participate too :) > > Everyday I have a list of tasks that I have to work on and when I finish, > I like to separate the changes of each task by commit. > >

[fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wednesday, June 4, 2014, Alysson Gonçalves de Azevedo < agalys...@gmail.com > wrote: > I started to use fossil just today, but let me participate too :) > > Everyday I have a list of tasks that I have to work on and when I finish, > I like to separate the changes of each task by commit. > > To

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

I've heard git allows this, and occasionally wished for it. As it stands currently, it's not possible with fossil. There is a degree of freedom in this regard using the fossil "stash", though, which can be used with some file jigging to separate two (or more?) logical ideas that one wants committe

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

I started to use fossil just today, but let me participate too :) Everyday I have a list of tasks that I have to work on and when I finish, I like to separate the changes of each task by commit. To do that, I just open GUI, check the lines of the files that i want to commit. (Just like this print

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On 6/4/2014 10:50, Richard Hipp wrote: The staging area complicates the interface. Perhaps you will add some of this to the Fossil vs Git wiki page. (Section 3.4?) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wed, Jun 4, 2014 at 1:34 PM, Richard Hipp wrote: > On Wed, Jun 4, 2014 at 2:20 PM, Nico Williams wrote: >> >> I never need to diff the staging area to the HEAD. Only the workspace >> to the HEAD+staging area, which is what git diff does. > > > Huh. I didn't not realize that was the default b

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

Thus said Richard Hipp on Wed, 04 Jun 2014 14:34:31 -0400: > It clearly would not work for me. As as an amateur user of Git, Git wasn't working for me---perhaps this is simply due to misunderstanding ``core'' features of Git. At any rate, thanks to Git I discovered Fossil and have been pleased

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wed, Jun 4, 2014 at 2:20 PM, Nico Williams wrote: > I never need to diff the staging area to the HEAD. Only the workspace > to the HEAD+staging area, which is what git diff does. > Huh. I didn't not realize that was the default behavior for Git. It clearly would not work for me. I'm typic

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

sent too soon. On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp wrote: > The staging area is another element of state on a check-out. It is one more > thing that the developer must keep in mind. Better to minimize the amount > of "mind-space" required for the VCS in order to leave as much mind-spa

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wed, Jun 4, 2014 at 11:50 AM, Richard Hipp wrote: > On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams > wrote: >> Right, the index is a very light-weight mechanism for giving the user >> power in deciding what to commit. I.e., more fine-grained control >> than "choose what files to commit". > >

Re: [fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wed, Jun 4, 2014 at 11:58 AM, Nico Williams wrote: > > Right, the index is a very light-weight mechanism for giving the user > power in deciding what to commit. I.e., more fine-grained control > than "choose what files to commit". > My view is that the Git staging area (I really dislike the

[fossil-users] Index (was Re: git->fossil->git does not obtain the same commit hashes.)

On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal wrote: > On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams > wrote: >> You're mixing things up :) Rebase is just a script around "new branch >> starting at given base, cherry-pick all the commits from the base to >> the head of what's being rebased". It