What's cooking in git.git (topics)

4 messages, 4 authors, 2016-06-15 · open the first message on its own page

What's cooking in git.git (topics)

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:16

Here are the topics that have been cooking.  Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.  The topics list the commits in reverse chronological
order.

* lh/submodule (Tue Jun 12 09:05:21 2007 +0200) 5 commits
 + Add gitmodules(5)
 + git-submodule: give submodules proper names
 + Rename sections from "module" to "submodule" in .gitmodules
 + git-submodule: remember to checkout after clone
 + t7400: barf if git-submodule removes or replaces a file

Soon to be merged to 'master' as 1.5.3 material, but still needs a
trivial fix to the Documentation/gitmodules.txt, though.

* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
 + filter-branch: subdirectory filter needs --full-history
 + filter-branch: Simplify parent computation.
 + Teach filter-branch about subdirectory filtering
 + filter-branch: also don't fail in map() if a commit cannot be
   mapped
 + filter-branch: Use rev-list arguments to specify revision ranges.
 + filter-branch: fix behaviour of '-k'
 + filter-branch: use $(($i+1)) instead of $((i+1))
 + chmod +x git-filter-branch.sh
 + filter-branch: prevent filters from reading from stdin
 + t7003: make test repeatable
 + Add git-filter-branch

Soon to be merged to 'master' as 1.5.3 material, but still needs
documentation, and culling of empty side branches.

* fl/cvsserver (Thu Jun 7 16:57:01 2007 +0200) 1 commit
 + cvsserver: Add some useful commandline options

To merge.

* gp/branch (Sat Jun 9 12:40:35 2007 +0000) 1 commit
 + git-branch: cleanup config file when deleting branches

To merge.

* jc/remote (Sat Jun 9 11:01:23 2007 -0700) 6 commits
 + git-push: Update description of refspecs and add examples
 + remote.c: "git-push frotz" should update what matches at the
   source.
 + remote.c: fix "git push" weak match disambiguation
 + remote.c: minor clean-up of match_explicit()
 + remote.c: refactor creation of new dst ref
 + remote.c: refactor match_explicit_refs()

To merge; this is an fix to fairly annoying breakage.

* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
 + git-svn: allow dcommit to retain local merge information

Hoping to be able to merge it to 'master', as it would be a big
usability improvement for people who use "git to merge because
SVN cannot" (without this, life ater such a merge will
unfortunately be miserable).

* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits
 + builtin-add: simplify (and increase accuracy of) exclude handling
 + dir_struct: add collect_ignored option

Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct.  Help is
appreciated.

* jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits
 + Extend --pretty=oneline to cover the first paragraph,
 + Lift 16kB limit of log message output

Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct.  Help is
appreciated.

* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
 - Quiet the output from git-init when cloning, if requested.
 - Add an option to quiet git-init.

Undecided.  I do not have anything against these two patches, as
they are obviously correct.  It's just the fact that nobody
complained my keeping these packed on 'pu' suggests there is not
much desire, and it is an extra option we need to maintain.

* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
 - filter-branch: always export GIT_DIR if it is set
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
 - make git barf when an alias changes environment variables
 - setup_git_directory: fix segfault if repository is found in cwd
 - test GIT_WORK_TREE
 - extend rev-parse test for --is-inside-work-tree
 - Use new semantics of is_bare/inside_git_dir/inside_work_tree
 - introduce GIT_WORK_TREE to specify the work tree
 - test git rev-parse
 - rev-parse: introduce --is-bare-repository
 - rev-parse: document --is-inside-git-dir

Undecided.  Some people would want to have a way to have GIT_DIR
point at somewhere unusual and still want to work from within a
subdirectory, which is probably a valid thing to support.  This
is not something I would use myself, so I am mostly worried
about the impact these changes may have on people who do not use
this feature.

Re: What's cooking in git.git (topics)

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:16

Hi,

On Wed, 13 Jun 2007, Junio C Hamano wrote:
* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
Isn't that convenient? That's already the second project the two JS'es are 
working together...
* jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits
 + Extend --pretty=oneline to cover the first paragraph,
 + Lift 16kB limit of log message output

Hoping to be able to merge them to 'master', but haven't
convinced myself that these changes are correct.  Help is
appreciated.
I haven't had a chance to look at the patch yet, but the intention is 
sound.
* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
 - filter-branch: always export GIT_DIR if it is set
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
 - make git barf when an alias changes environment variables
 - setup_git_directory: fix segfault if repository is found in cwd
 - test GIT_WORK_TREE
 - extend rev-parse test for --is-inside-work-tree
 - Use new semantics of is_bare/inside_git_dir/inside_work_tree
 - introduce GIT_WORK_TREE to specify the work tree
 - test git rev-parse
 - rev-parse: introduce --is-bare-repository
 - rev-parse: document --is-inside-git-dir

Undecided.  Some people would want to have a way to have GIT_DIR
point at somewhere unusual and still want to work from within a
subdirectory, which is probably a valid thing to support.  This
is not something I would use myself, so I am mostly worried
about the impact these changes may have on people who do not use
this feature.
Yeah, it is something to worry about. As far as I am concerned, these 
changes are too deep for too obscure a feature.

But then, I see that people need it.

And I can't think of a better way to implement it. So unless somebody 
comes up with a nice solution, I think we should live with it, rather than 
let it simmer in pu.

Ciao,
Dscho

Re: What's cooking in git.git (topics)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:16


On Wed, 13 Jun 2007, Johannes Schindelin wrote:
quoted
* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
Isn't that convenient?
Heh. I heard a perfect Dana Carvey "Isn't that conveeenient" in my head on 
that line (SNL "Church Lady" skits, in case people don't make the 
connection).

Was that intentional, or is it just my brain that is fried?

"Isn't that speecial?"
That's already the second project the two JS'es are working together...
There's clearly something deeper to this notion of two-letter naming that 
Junio uses.  I used to think it was obviously flawed, but Junio may really 
be onto something here..

			Linus

Re: What's cooking in git.git (topics)

From: Matthias Lederhofer <hidden>
Date: 2016-06-15 22:43:17

Junio C Hamano [off-list ref] wrote:
* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
 - filter-branch: always export GIT_DIR if it is set
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
 - make git barf when an alias changes environment variables
 - setup_git_directory: fix segfault if repository is found in cwd
 - test GIT_WORK_TREE
 - extend rev-parse test for --is-inside-work-tree
 - Use new semantics of is_bare/inside_git_dir/inside_work_tree
 - introduce GIT_WORK_TREE to specify the work tree
 - test git rev-parse
 - rev-parse: introduce --is-bare-repository
 - rev-parse: document --is-inside-git-dir

Undecided.  Some people would want to have a way to have GIT_DIR
point at somewhere unusual and still want to work from within a
subdirectory, which is probably a valid thing to support.  This
is not something I would use myself, so I am mostly worried
about the impact these changes may have on people who do not use
this feature.
The only problem I know of up to now seems the one which happened with
git-filter-branch: if GIT_DIR is set and GIT_WORK_TREE/core.worktree is
set the specified working tree is used instead of cwd.

So for users not using GIT_WORK_TREE/core.worktree there should be no
problem.  There might be problems if someone distributes scripts for
git which expect the old behaviour and the user specified the
worktree.  OTOH the fix is to export GIT_WORK_TREE=. which does not
break the script for older versions of git versions and is quite
short (i.e. should not require any restructuring of the script).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help