headers
Daniel Barkalow | 1 Feb 2010 01:34

Re: [PATCH v6] add --summary option to git-push and git-fetch

On Fri, 29 Jan 2010, Junio C Hamano wrote:

> As I said in my review during the earlier rounds, I do not know if it is
> safe to use the flags and do the traversal inside this same process.  You
> may be clearing the flags to protect your traversal (one per branch) from
> stepping on each other, but how would this affect the use of object flags
> in existing parts of the "push" machinery?  Is the reasoning that even if
> push calls into traversal code and after it walked the commit ancestry for
> its own purpose, your addition will clear the flags and existing code will
> never look at object flags again, so this new code is free to use them and
> all is Ok?  As long as you made sure that nobody looks at object flags you
> modified, then I am fine with that---I just don't know if that is what is
> happening here, and that is why I am asking.
> 
> I'd need help from the usual "transport" suspects for this patch.

I'm pretty sure that the built-in transport implementations all clear the 
flags themselves before using them. The fetch side has to be able to fetch 
twice in order to handle tags, and the push side has to be able to push to 
multiple destinations. So both parts should be defending themselves 
against flags that are specificly confusing to that part.

	-Daniel
*This .sig left intentionally blank*
Permalink | Reply | 0 comments |
headers
Larry D'Anna | 1 Feb 2010 01:57

Re: [PATCH v6] add --summary option to git-push and git-fetch

* Junio C Hamano (gitster <at> pobox.com) [100130 02:16]:
> Larry D'Anna <larry <at> elder-gods.org> writes:
> > +
> > +	object = parse_object(sha1); 
> > +	if (!object)
> > +	    die("bad object %s", arg);
> > +	
> > +	object_deref = deref_tag(object, NULL, 0); 
> > +	if (object_deref && object_deref->type == OBJ_COMMIT)
> > +	    if (flags_to_clear)
> > +		clear_commit_marks((struct commit *) object_deref, flags_to_clear); 
> > +
> > +	object->flags |= flags ^ local_flags; 
> 
> This smells somewhat fishy---what is the reason this "peel and mark" needs
> to be done only in this codepath, and none of the other callers of
> get_reference() need a similar logic, for example?
> 
> In general, why do you need to sprinkle clear-commit-marks all over the
> place?  

My idea was to call call clear_commit_marks on the "roots" of the revision arg,
and since handle_revision_arg looks up those roots in several different places,
i had to put clear_commit_marks in each of those places.  the reason the patch
is particularly ugly in this spot is that the other places where i put
clear_commit_marks, I already had a struct commit *, but here i just had a
object that might be a tag.

> This is not a rhetorical question (I haven't reviewed all the
> codepath involved for quite some time), but naïvely it appears it would be
(Continue reading)

Permalink | Reply | 3 comments |
headers
H. Peter Anvin | 1 Feb 2010 02:18
Favicon

Wishlist for branch management

A wishlist for better handling of branches:

git clone --branches

... git clone, with the additional step of setting up local branches for
each one of the remote branches.

git branch --current

... list the current branch name, for use in scripts.  Equivalent to:
	"git branch | grep '^\*' | cut -c3-"

git push --current

... push the current branch, and only the current branch...

	-hpa

--

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
Permalink | Reply | 4 comments |
headers
Björn Steinbrink | 1 Feb 2010 02:31
Picon
Picon

Re: Wishlist for branch management

On 2010.01.31 17:18:39 -0800, H. Peter Anvin wrote:
> git branch --current
> 
> ... list the current branch name, for use in scripts.  Equivalent to:
> 	"git branch | grep '^\*' | cut -c3-"

In scripts, plumbing should be used. I use:
	git rev-parse --symbolic-full-name HEAD

This gives either the full refname of the checked out branch head, e.g.
refs/heads/master, or HEAD in case of a detached HEAD.

> git push --current
> 
> ... push the current branch, and only the current branch...

Unless you want to push to a different ref remotely, e.g. pushing
refs/heads/master-public to refs/heads/master, you can use:
	git push <remote> HEAD

For example, when refs/heads/master is checked out, then:
	git push origin HEAD
acts the same as:
	git push origin refs/heads/master

Björn
Permalink | Reply | 1 comment |
headers
Ron Garret | 1 Feb 2010 02:33
Favicon

GIT_WORK_TREE environment variable not working

What am I doing wrong here?

[ron <at> mickey:~/devel/gittest]$ pwd
/Users/ron/devel/gittest
[ron <at> mickey:~/devel/gittest]$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#  git/
nothing added to commit but untracked files present (use "git add" to 
track)
[ron <at> mickey:~/devel/gittest]$ cd
[ron <at> mickey:~]$ export GIT_WORK_TREE=/Users/ron/devel/gittest
[ron <at> mickey:~]$ git status
fatal: Not a git repository (or any of the parent directories): .git
[ron <at> mickey:~]$ git status --work-tree=/Users/ron/devel/gittest
fatal: Not a git repository (or any of the parent directories): .git
[ron <at> mickey:~]$
Permalink | Reply | 2 comments |
headers
Ben Walton | 1 Feb 2010 03:15
Picon
Picon

[PATCH 1/2] configure: Allow GIT_ARG_SET_PATH to handle --without-PROGRAM

Add an optional second argument to both GIT_ARG_SET_PATH and
GIT_CONF_APPEND_PATH such that any value of the second argument will
enable configure to set NO_$PROGRAM in addition to an empty
$PROGRAM_PATH.  This is initially useful for allowing configure to
disable the use of python, as the remote helper code has nothing
leveraging it yet.

The Makefile already recognizes NO_PYTHON, but configure provided no
way to set it appropriately.

Signed-off-by: Ben Walton <bwalton <at> artsci.utoronto.ca>
---
 configure.ac |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 229140e..9eaae7d 100644
--- a/configure.ac
+++ b/configure.ac
 <at>  <at>  -23,21 +23,32  <at>  <at>  AC_DEFUN([GIT_CONF_APPEND_LINE],
 # GIT_ARG_SET_PATH(PROGRAM)
 # -------------------------
 # Provide --with-PROGRAM=PATH option to set PATH to PROGRAM
+# Optional second argument allows setting NO_PROGRAM=YesPlease if
+# --without-PROGRAM version used.
 AC_DEFUN([GIT_ARG_SET_PATH],
 [AC_ARG_WITH([$1],
  [AS_HELP_STRING([--with-$1=PATH],
                  [provide PATH to $1])],
- [GIT_CONF_APPEND_PATH($1)],[])
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ben Walton | 1 Feb 2010 03:15
Picon
Picon

[PATCH 0/2] configure tweaks for NO_PYTHON

The following patches enable a user to ./configure git with python
disabled.  There is nothing using the remote helper libraries yet.  I
noticed this missing capability after the recent rpm .spec thread.

Ben Walton (2):
  configure: Allow GIT_ARG_SET_PATH to handle --without-PROGRAM
  configure: Allow --without-python

 configure.ac |   17 ++++++++++++++---
 1 files changed, 14 insertions(+), 3 deletions(-)
Permalink | Reply | 4 comments |
headers
Ben Walton | 1 Feb 2010 03:15
Picon
Picon

[PATCH 2/2] configure: Allow --without-python

This patch allows someone to use configure to build git while at the
same time disabling the python remote helper code.  It leverages the
ability of GIT_ARG_SET_PATH to accept an optional second argument
indicating that --without-$PROGRAM is acceptable.

Signed-off-by: Ben Walton <bwalton <at> artsci.utoronto.ca>
---
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9eaae7d..914ae57 100644
--- a/configure.ac
+++ b/configure.ac
 <at>  <at>  -288,7 +288,7  <at>  <at>  GIT_ARG_SET_PATH(shell)
 GIT_ARG_SET_PATH(perl)
 #
 # Define PYTHON_PATH to provide path to Python.
-GIT_ARG_SET_PATH(python)
+GIT_ARG_SET_PATH(python, allow-without)
 #
 # Define ZLIB_PATH to provide path to zlib.
 GIT_ARG_SET_PATH(zlib)
--

-- 
1.6.5.3
Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 1 Feb 2010 04:22
Favicon

Re: Wishlist for branch management

On 01/31/2010 05:31 PM, Björn Steinbrink wrote:
> 
>> git push --current
>>
>> ... push the current branch, and only the current branch...
> 
> Unless you want to push to a different ref remotely, e.g. pushing
> refs/heads/master-public to refs/heads/master, you can use:
> 	git push <remote> HEAD
> 
> For example, when refs/heads/master is checked out, then:
> 	git push origin HEAD
> acts the same as:
> 	git push origin refs/heads/master
> 

Whatever is used, it should respect the configuration.  This requires
knowing what the configuration is set up as.

	-hpa

--

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Feb 2010 04:35
Picon
Picon
Favicon
Gravatar

What's cooking in git.git (Jan 2010, #10; Sun, 31)

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.

We are passed 1.7.0-rc1; please test "master" branch to avoid giving
regressions to end users.  Thanks.

--------------------------------------------------
[Graduated to "master"]

* jl/diff-submodule-ignore (2010-01-24) 2 commits
  (merged to 'next' on 2010-01-25 at fbe713d)
 + Teach diff --submodule that modified submodule directory is dirty
 + git diff: Don't test submodule dirtiness with --ignore-submodules
 (this branch uses jc/ce-uptodate.)

* jc/ce-uptodate (2010-01-24) 1 commit
  (merged to 'next' on 2010-01-25 at fbe713d)
 + Make ce_uptodate() trustworthy again
 (this branch is used by jl/diff-submodule-ignore.)

* gp/maint-cvsserver (2010-01-26) 1 commit
 + git-cvsserver: allow regex metacharacters in CVSROOT

* fk/threaded-grep (2010-01-25) 1 commit
  (merged to 'next' on 2010-01-26 at 687b2a6)
 + Threaded grep
 (this branch uses jc/grep-q.)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane