In general, in areas like contrib/ where there is a volunteer area
maintainer, unless the change something ultra-urgent (e.g. serious
security fix) and the area maintainer is unavailable, I'm really
reluctant to bypass and take a single patch that adds many things
that are independent from each other.
Who do you see as volunteer area maintainer for contrib/subtree?
My best guess would be Dave. And he already indicated earlier in the
thread to be ok with the combined patch as long as you are ok with it.
Let's be clear. Junio owns the project so what he says goes, no
question. I provided some review feedback which I thought would help
the patches get in more easily. We really shouldn't be adding multiple
features in one patch. This is easily separated into multiple patches.
Then there is the issue of testcases. We should NOT have git-subtree go
back to the pre-merge _ad_hoc_ test environment. We should use what the
usptream project uses. That will make mainlining this much easier in
the future.
If Junio is ok with overriding my decisions here, that's fine. But I
really don't understand why you are so hesitant to rework the patches
when it should be realtively easy. Certainly easier than convincing me
they are in good shape currently. :)
-David
In general, in areas like contrib/ where there is a volunteer area
maintainer, unless the change something ultra-urgent (e.g. serious
security fix) and the area maintainer is unavailable, I'm really
reluctant to bypass and take a single patch that adds many things
that are independent from each other.
Who do you see as volunteer area maintainer for contrib/subtree?
My best guess would be Dave. And he already indicated earlier in the
thread to be ok with the combined patch as long as you are ok with it.
Let's be clear. Junio owns the project so what he says goes, no
question. I provided some review feedback which I thought would help
the patches get in more easily. We really shouldn't be adding multiple
features in one patch. This is easily separated into multiple patches.
Then there is the issue of testcases. We should NOT have git-subtree go
back to the pre-merge _ad_hoc_ test environment. We should use what the
usptream project uses. That will make mainlining this much easier in
the future.
If Junio is ok with overriding my decisions here, that's fine. But I
really don't understand why you are so hesitant to rework the patches
when it should be realtively easy. Certainly easier than convincing me
they are in good shape currently. :)
If it's so easy to rework these patches then please do so yourself.
It's been ages since I've worked on this so I would also have to
re-discover everything.
And yes it's ugly, but so is the code that you've merged in.
Which you haven't changed a single line in after merging. So it's still
the version from Avery which hasn't been maintained for the last two years.
This ball of wax is still a big improvement in my opinion.
Feel free to scrape the github forks for improvements on your own,
cleanup the code style and create fitting test cases.
But if you intend on taking in changes only when presented to you on a
silver patter, then we're better of with subtree removed from the
contrib tree.
What would a random user have to do to get a patch in? I've found a
number of subtree related mails on the git-user list go completely
unanswerd.
Amongst them a patch from James Nylen wich seems very reasonable.
--
Met vriendelijke groet / Regards,
Herman van Rink
Initfour websolutions
In general, in areas like contrib/ where there is a volunteer area
maintainer, unless the change something ultra-urgent (e.g. serious
security fix) and the area maintainer is unavailable, I'm really
reluctant to bypass and take a single patch that adds many things
that are independent from each other.
Who do you see as volunteer area maintainer for contrib/subtree?
My best guess would be Dave. And he already indicated earlier in the
thread to be ok with the combined patch as long as you are ok with it.
Let's be clear. Junio owns the project so what he says goes, no
question. I provided some review feedback which I thought would help
the patches get in more easily. We really shouldn't be adding multiple
features in one patch. This is easily separated into multiple patches.
Then there is the issue of testcases. We should NOT have git-subtree go
back to the pre-merge _ad_hoc_ test environment. We should use what the
usptream project uses. That will make mainlining this much easier in
the future.
If Junio is ok with overriding my decisions here, that's fine. But I
really don't understand why you are so hesitant to rework the patches
when it should be realtively easy. Certainly easier than convincing me
they are in good shape currently. :)
If it's so easy to rework these patches then please do so yourself.
It's been ages since I've worked on this so I would also have to
re-discover everything.
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
--
David Michael Barr
From: James Nylen <hidden> Date: 2016-06-15 22:55:07
On Fri, Oct 26, 2012 at 9:58 AM, David Michael Barr [off-list ref] wrote:
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
David, I think that would be great. I wish I had time to work on
unwrapping the current patch but I don't. I will definitely re-submit
my (simple) patch after this is done though.
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
What is the status of the work on git-subtree described in this thread?
It looks like it's stalled.
From: Paul Campbell <hidden> Date: 2016-06-15 22:56:17
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal [off-list ref] wrote:
David Michael Barr <b <at> rr-dav.id.au> writes:
quoted
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
What is the status of the work on git-subtree described in this thread?
It looks like it's stalled.
I hadn't been aware of that patch. Reading the thread David Michael
Barr was going to try picking the patch apart into sensible chunks.
My own patches, some of which I've submitted to the list, appear to be
tackling a couple of the same things (e.g. storing subtree metadata in
an ini file). Mine can be found here
(https://github.com/kemitix/git/commits/subtree-usability), including
some I've not submitted yet.
If this work is still needing done I'd like to volunteer.
--
Paul [W] Campbell
From: David Michael Barr <hidden> Date: 2016-06-15 22:56:17
On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell [off-list ref] wrote:
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal [off-list ref] wrote:
quoted
David Michael Barr <b <at> rr-dav.id.au> writes:
quoted
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
What is the status of the work on git-subtree described in this thread?
It looks like it's stalled.
I hadn't been aware of that patch. Reading the thread David Michael
Barr was going to try picking the patch apart into sensible chunks.
Sorry for not updating the thread. I did end up moving onto other things.
I quickly realised the reason for globbing all the patches together was
that the individual patches were not well contained.
That is single patches with multiple unrelated changes and multiple
patches changing the same things in different directions.
To me this means that the first step is to curate the history.
If this work is still needing done I'd like to volunteer.
You're most welcome. Sorry again for abandoning the thread.
--
David Michael Barr
From: Paul Campbell <hidden> Date: 2016-06-15 22:56:17
On Sat, Mar 2, 2013 at 11:21 AM, David Michael Barr [off-list ref] wrote:
On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell [off-list ref] wrote:
quoted
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal [off-list ref] wrote:
quoted
David Michael Barr <b <at> rr-dav.id.au> writes:
quoted
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
What is the status of the work on git-subtree described in this thread?
It looks like it's stalled.
I hadn't been aware of that patch. Reading the thread David Michael
Barr was going to try picking the patch apart into sensible chunks.
Sorry for not updating the thread. I did end up moving onto other things.
I quickly realised the reason for globbing all the patches together was
that the individual patches were not well contained.
That is single patches with multiple unrelated changes and multiple
patches changing the same things in different directions.
To me this means that the first step is to curate the history.
quoted
If this work is still needing done I'd like to volunteer.
You're most welcome. Sorry again for abandoning the thread.
--
David Michael Barr
Okay, I'll start picking the patch apart this week then feedback when
I have a plan to tackle it all.
--
Paul [W] Campbell
From: Paul Campbell <hidden> Date: 2016-06-15 22:56:18
On Sat, Mar 2, 2013 at 5:43 PM, Paul Campbell [off-list ref] wrote:
On Sat, Mar 2, 2013 at 11:21 AM, David Michael Barr [off-list ref] wrote:
quoted
On Sat, Mar 2, 2013 at 9:05 AM, Paul Campbell [off-list ref] wrote:
quoted
On Fri, Mar 1, 2013 at 2:28 AM, Kindjal [off-list ref] wrote:
quoted
David Michael Barr <b <at> rr-dav.id.au> writes:
quoted
From a quick survey, it appears there are no more than 55 patches
squashed into the submitted patch.
As I have an interest in git-subtree for maintaining the out-of-tree
version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
to make some sense of the organic growth that happened on GitHub.
It doesn't appear that anyone else is willing to do this, so I doubt
there will be any duplication of effort.
What is the status of the work on git-subtree described in this thread?
It looks like it's stalled.
I hadn't been aware of that patch. Reading the thread David Michael
Barr was going to try picking the patch apart into sensible chunks.
Sorry for not updating the thread. I did end up moving onto other things.
I quickly realised the reason for globbing all the patches together was
that the individual patches were not well contained.
That is single patches with multiple unrelated changes and multiple
patches changing the same things in different directions.
To me this means that the first step is to curate the history.
quoted
If this work is still needing done I'd like to volunteer.
You're most welcome. Sorry again for abandoning the thread.
--
David Michael Barr
Okay, I'll start picking the patch apart this week then feedback when
I have a plan to tackle it all.
--
Paul [W] Campbell
From a comparison of the tip for helmo's subtree-updates branch and
the current master these are the changes and features that the patch
is providing. I've listed the changes briefly per file, with a note
of the general action I plan to take. This is based on a simple diff,
so some changes are actually reversions to recent commits, which I
have tried to note.
Makefile
* Regresses two recent commits (8165be064e and d86848228f)
* ACTION: Ignore file
README.md
* Adds a markdown readme file (that github likes to have in root)
* Includes some install instructions in a pseudo man page format
* The INSTALL file covers all the information contained and is more up-to-date
* ACTION: Ignore file
git-subtree.sh
* OPTS_SPEC
* pull/push: options for repository and refspec are both optional,
[<repository> [<refspec>]]
* new sub-command: pull-all
* new sub-command: push-all
* new sub-command: list
* new sub-command: from-submodule
* new sub-command: prune
* new sub-command: diff
* new option for push: --force
* Trailing slash on prefix is removed
* Different pretty log format in cmd_commit getting piped to set some
environment variables
* Would revert: a5b8e28e4e
* Ignoring this change
* Removes all tests in cmd_add to check that refspec is valid
* I've posted a patch with new tests to the list recently that would
go in here
* Change reference to 'commit' into 'refspec' in error message in cmd_add
* Stores subtree metadata in .gittrees as:
[subtree "$dir"]
url = $repository
path = $dir
branch = $refspec
* Inadvertently commited a change to the linefeed character in
cmd_split for the activity indicator
* cmd_pull/cmd_push: reads options from .gitrees if not provided on
the command line
* Implementation of cmd_diff
* fetches remote repo as a temporary git-remote then uses
git-diff-tree to compare before removing the temporary git-remote
* Implementation of cmd_list as plain wrapper to new functions subtree_list
* Iterates over subtrees listed in .gittrees and prints out their details
* Dubious about greps used to get list from .gittrees
* Implementation of cmd_from-submodule
* Converts a git-submodule into a git-subtree
* Implementation of cmd_prune
* Removes entries from .gittrees where the $dir is missing
* Dubious about greps used to get list from .gittrees
* Implementation of cmd_pull-all
* Performs a git-subtree pull for each subtree
* Dubious about greps used to get list from .gittrees
* Implementation of cmd_push-all
* Perfroms a git-subtree push for each subtree
* Dubious about greps used to get list from .gittrees
git-subtree.txt
* Adds brief descriptions for commands:
* pull-all
* push-all
* list
* from-submodule
* prune
* diff ("TO BE DOCUMENTED")
* Notes optional -f|--force for push sub-command
* fixes a typo in text for Example 1 (s/incldued/included/)
t/t7900.sh
* Add numeric comments for each test
* recently removed (144797d720) in master so don't add them back
* ACTION: Ignore file
test.sh
* Legacy tests
* ACTION: Ignore file
My next step will be to find the commits (from helmo's
subtree-updates-merged branch) that provide the features above that I
want to keep and cherry-pick them into a new branch (or two).
--
Paul [W] Campbell