On Fri, Apr 22, 2016 at 11:45 PM, Arnel wrote:
>
>
> Doesn't working on a branch marked private and merging it later (upon
> approval)
> essentially provide the benefits of "squashing" the commits? The only
> difference
> would be the branch commits themselves will not be visible on the upstream
>
On Sat, Apr 23, 2016 at 2:06 AM, Steve Schow wrote:
>
>
> if so, not a big deal then, just have to use wrapper scripts to make sure
> to follow your work flow, always create a new branch on the first commit
> for any ticket. I will probably use a cookie or something to make sure
> while working o
On Sat, Apr 23, 2016 at 1:04 AM, Steve Schow wrote:
>
> Nice work flow…
>
Thanks. It is simplified to highlight the key parts.
> In the above workflow, here are my questions:
>
> 1 - step#4 is fine because dev is working on a branch. do you have any
> mechanisms in place to prevent them from
On Sat, Apr 23, 2016 at 12:06 AM, Steve Schow wrote:
>
> On Apr 22, 2016, at 11:34 PM, Ron W wrote:
>
> My team's wrapper for Fossil does the following (from memory, so might not
> be exactly right):
>
> On "branch new":
>fossil commit --allow-empty --branch $bname -m "$comment (Issue
> [$is
On Apr 22, 2016, at 11:34 PM, Ron W wrote:
> My team's wrapper for Fossil does the following (from memory, so might not be
> exactly right):
>
> On "branch new":
>fossil commit --allow-empty --branch $bname -m "$comment (Issue [$issue])"
>fossil tag add --propagate issue $bname $issue
On Fri, Apr 22, 2016 at 9:03 PM, Steve Schow wrote:
>
> Right well I’m just trying to figure out a way to automate thing so the
> dev never has to worry about copy and pasting any kind of ticket or checkin
> numbers from one place to another. I want it to just happen automatically
> through wrap
On Apr 22, 2016, at 10:35 PM, Ron W wrote:
>
> At work, my team keeps autosync on. We do all our code changes in branches.
> Our workflow is:
> 1. An issue ticket is created, describing either a problem or a specification.
> 2. (wait until issue is reviewed and approved)
> 3. A branch is create
On Fri, Apr 22, 2016 at 8:33 PM, Steve Schow wrote:
>
>
> the question about auto-sync is only an open ended question. There could
> be some work flows that may work with or without it as far as i can tell,
> but i’m just asking about what others might be doing..
>
> with auto-sync…anyone who com
Hi Richard,
On 22 April 2016 07:07PM, Richard Hipp wrote:
> On 4/22/16, Steve Schow wrote:
> > 2 - I notice fossil doesn’t endorse or seem to directly support the
> > squashing of commits.
>
> Right. The Fossil philosophy is different from Git. In Fossil, we
> work hard to preserve *all* histor
Beautiful explanation! Thank you! The dot clicking functionality is really
very cool, that actually makes everything way easy to deal with, as far as code
review…especially with the background color stuff in there. The Webgui is
starting to make more sense to me as I look at these examples.
On 4/22/16, Steve Schow wrote:
>
> Im not sure if you’re saying a merge here would
> merge multiple commits from one branch into a single commit on the dest
> branch? You said it preserves the history, but that would infer that the
> merge would not squash the commits in the process.
>
Here is
On Apr 22, 2016, at 5:07 PM, Richard Hipp wrote:
> If you want see a sequence of changes as a single diff, bring up a
> timeline that shows all the changes, click on the "node" of the
> origin, then click on the last check-in, then it will show you a diff
> between those two nodes.
this works g
On Apr 22, 2016, at 5:07 PM, Richard Hipp wrote:
> On 4/22/16, Steve Schow wrote:
>>
>> 1 - I notice tickets numbers are not automatically cross linked with
>> commits.
>
> Links are automatic if you include the ticket number [nn]
> somewhere in the check-in
> comment. See the check-in a
First let me state the purpose of gatekeeping is not because I don’t trust devs
not to delete something. Its to keep the mainline containing at all times,
only “approved" code. I am not even worried about perms and stuff or devs
trying to skirt around it, everyone I work with is friends, this
On 22 Apr 15:38, Steve Schow wrote:
> 3 - whether to use auto-sync or not.
I think you are making things overly complicated in question 3.
If I understand properly, you want one trusted person to approve code
before it gets into trunk on the main repository. Here is a policy that
could accomplish
On 4/22/16, Steve Schow wrote:
>
> 1 - I notice tickets numbers are not automatically cross linked with
> commits.
Links are automatic if you include the ticket number [nn]
somewhere in the check-in
comment. See the check-in at
https://www.sqlite.org/src/timeline?c=ab9d279f40f81e5a for a rec
I have just discovered fossil and I am kind of blown away by all it can do! I
love how simple this is to install and administrate for small projects. The
other competing products like GitLab or Phabricator, etc, are orders of
magnitude too complicated for small projects that just need some src
17 matches
Mail list logo
