On Fri, Mar 20, 2015 at 7:26 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
Or the opposite. Stash and partial pop, which apparently Fossil can
already handle simply by using the ``right'' diff tool. For example, I
configured Fossil to use idiff as my gdiff command
$ fossil set
Thus said Abilio Marques on Fri, 20 Mar 2015 13:58:33 -0430:
Then I start to work in a new feature, and I add 10 functions (I will
only show one here).
Now that you know about it, can the start of a new feature also involve
another fossil open of the repository for said feature?
Thanks,
Thus said Richard Hipp on Fri, 20 Mar 2015 13:04:44 -0400:
(1) Make logically separate changes in separate check-outs so that
they are easy to test and commit separately.
I think this ability to have multiple checkouts of the same repository
is a much more elegant solution, but it does
++1
From: Scott Robison
Sent: Friday, March 20, 2015 11:08 PM
On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich s...@stef.rs wrote:
If we are discussing partial, I'm more interested in partial checkouts than
partial commits, i.e. having the ability to checkout a specific directory only.
Thus said Ron W on Fri, 20 Mar 2015 13:19:58 -0400:
Never too late to stash. If I decide I need to split out changes
already made, I stash the files, then do fossil stash gdiff to
selectively (re) apply the stashed changes, then build/test/commit.
gdiff allows you to selectively
Thus said Marcel Graf on Fri, 20 Mar 2015 18:30:11 +0100:
Imho, the missing piece would be stash having means to do partial
stashing (finer than on file-by-file base). This the would allow to do
these splittings of a mixed up check-outs a bit easier (including
testing before committing,
Thus said Ron W on Fri, 20 Mar 2015 15:56:51 -0400:
I've never seen a non-gui, interactive merge, so I don't know how
feasible to create such a tool
Here's a non-gui, interactive merge (I didn't show it, but there is also
an edit command which invokes $EDITOR on just the chunk in
On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques abili...@gmail.com wrote:
I personally would like a selective stash. Perhaps one where you can
selectively push some changes (then fossil could proceed to remove them
from the actual files), or selectively pop/apply some changes (but I
imagine
On 3/20/15, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques abili...@gmail.com
wrote:
I personally would like a selective stash. Perhaps one where you can
selectively push some changes (then fossil could proceed to remove them
from the actual
Can we define partial commit ?
Are we talking about when I code, code, code and then realize
that I've got two features' worth of new material and would like to
separate them so that Feature B is held back, Feature A is applied
(and yes, tested, etc., etc) and committed, then Feature B is applied
Yes, that's my vision of it. I've come to several situations in which
feature A and feature B share the same file.
I then proceed to remove all the code from feature B, run the tests for the
A, pass them, then commit. Then apply back the lines from feature B,
retest, pass, and commit.
Actually
On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques abili...@gmail.com
wrote:
I personally would like a selective stash.
Yes, I would find selective stash save/apply useful.
But I see the dangers of partial commit of git's staging area. I admit,
I've abused that myself to commit a comment or
After a yesterday's email entitled “is this a crazy idea?” meant to ask
about a shim ended in a really interesting discussion about select specific
changes to files, I think we could give that idea a chance to live (just as
an idea, for the time being).
I've personally gone through times where
: [fossil-users] Select specific changes within files
...We shouldn't waste too much time implementing that capability when there are
other more useful features that could be added instead...
___
fossil-users mailing list
fossil-users@lists.fossil
On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich s...@stef.rs wrote:
If we are discussing partial, I'm more interested in partial checkouts
than partial commits, i.e. having the ability to checkout a specific
directory only. Now that would be useful for us with big source trees where
there
Stephan Beal wrote:
On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques abili...@gmail.com
mailto:abili...@gmail.com wrote:
I personally would like a selective stash. Perhaps one where you can
selectively push some changes (then fossil could proceed to remove
them from the actual
On Fri, Mar 20, 2015 at 2:28 PM, Abilio Marques abili...@gmail.com wrote:
So including that patch right now seems really important. But I have a mix
between the patch and the unfinished (and also untested).
Until yesterday, what did I do?
fossil stash snapshot
go to the editor, find the
On 2015-03-20T07:26:53 -0430
Abilio Marques abili...@gmail.com wrote:
I personally would like a selective stash.
This seems like the best of all worlds: You get the clean separate
commits typical of git, but with each of those commits actually
compiled and tested.
I tried to put this together
On 3/20/15, Richard Hipp d...@sqlite.org wrote:
On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
On 2015-03-20 09:02:32, Richard Hipp wrote:
(...)
I'm still having trouble understanding how the partial commit would be
*useful*, though.
Also, ideally you're working in a flow anyways (the
Ok, in an attempt to provide a short example:
The code is working, I have tests, yet I don't test for memory leaks.
That's my current scenario. A code snippet follows:
void functionA() {
char *thisWillLeak;
...
thisWillLeak = malloc(1024);
...
// never free nor return the memory
}
On Fri, Mar 20, 2015 at 7:56 AM, Abilio Marques abili...@gmail.com wrote:
Yet before that, I knew about stash. But sometimes it was already too late
to simply stash and begin doing some other changes, as both changes were
already in the file.
Never too late to stash. If I decide I need to
On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf graf.m.ml+sbf...@gmail.com
wrote:
On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp d...@sqlite.org wrote:
On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
...
in itself). So you end up with intermingled changes which one would
like to split
On 2015-03-20 13:04:44, Richard Hipp wrote:
(...)
The way I deal with this in SQLite is:
(1) Make logically separate changes in separate check-outs so that
they are easy to test and commit separately. (...)
That's the sort of flow-interrupting context switch I was referring to
on one hand,
On Fri, Mar 20, 2015 at 2:02 PM, Richard Hipp d...@sqlite.org wrote:
I agree with Stephan, except to note that some repositories do not
store code. If you are checking in changes to text documentation,
then maybe testing is not as important and a partial commit would be
ok.
I believe it can
On Fri, Mar 20, 2015 at 10:26 AM, bch brad.har...@gmail.com wrote:
I'm still confused about what complete or split means in the
contexts that I think people are using this --
If I accidentally code two different logical thoughts into a single
file -- and so they are combined, and uncommitted
On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp d...@sqlite.org wrote:
On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
...
in itself). So you end up with intermingled changes which one would
like to split cleanly.
The way I deal with this in SQLite is:
...
(2) On the occasions when I
On Fri, Mar 20, 2015 at 5:56 AM, Abilio Marques abili...@gmail.com wrote:
Neat ideas already popped. Here I copy/paste some fragments of them:
fossil diff --tk --partial-commit (Then, an automatic fossil stash is
performed where the original modified files are stored. The files left in
the
On 2015-03-20 09:02:32, Richard Hipp wrote:
(...)
I'm still having trouble understanding how the partial commit would be
*useful*, though.
Some people like their metadata (i.e. fossil's commit message log) to
match up with what they were doing in the files. You go to your file, you
begin to
On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
On 2015-03-20 09:02:32, Richard Hipp wrote:
(...)
I'm still having trouble understanding how the partial commit would be
*useful*, though.
Also, ideally you're working in a flow anyways (the deep meditative
state where stuff gets done
I'm still confused about what complete or split means in the
contexts that I think people are using this --
If I accidentally code two different logical thoughts into a single
file -- and so they are combined, and uncommitted -- why would tools
or facilities to aid making-discrete two different
On Fri, Mar 20, 2015 at 3:32 PM, Marcel Graf graf.m.ml+sbf...@gmail.com
wrote:
I was more thinking about a command line only version of stash/snapshot
--interactive asking for each file if i want it entirely or split and in
case of the latter, letting me select each chunk without the use of an
On Fri, Mar 20, 2015 at 7:14 PM, Ron W ronw.m...@gmail.com wrote:
On Fri, Mar 20, 2015 at 1:30 PM, Marcel Graf graf.m.ml+sbf...@gmail.com
wrote:
On Fri, Mar 20, 2015 at 6:04 PM, Richard Hipp d...@sqlite.org wrote:
On 3/20/15, Martin S. Weber ephae...@gmx.net wrote:
...
in itself). So
On Fri, Mar 20, 2015 at 4:55 PM, Steve Stefanovich s...@stef.rs wrote:
If we are discussing partial, I'm more interested in partial checkouts
than partial commits, i.e. having the ability to checkout a specific
directory only. Now that would be useful for us with big source trees where
there
33 matches
Mail list logo
