* [PATCH 2/2] update-hook-example: optionally allow non-fast-forward
From: Dmitry Potapov @ 2008-06-25 8:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Dmitry Potapov
In-Reply-To: <1214382416-6687-1-git-send-email-dpotapov@gmail.com>
Sometimes it is desirable to have non-fast-forward branches in a
shared repository. A typical example of that is the 'pu' branch.
This patch extends the format of allowed-users and allow-groups
files by using the '+' sign at the beginning as the mark that
non-fast-forward pushes are permitted to the branch.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/howto/update-hook-example.txt | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
index a8d3bae..e1e2889 100644
--- a/Documentation/howto/update-hook-example.txt
+++ b/Documentation/howto/update-hook-example.txt
@@ -65,7 +65,7 @@ function info {
# Implement generic branch and tag policies.
# - Tags should not be updated once created.
-# - Branches should only be fast-forwarded.
+# - Branches should only be fast-forwarded unless their pattern starts with '+'
case "$1" in
refs/tags/*)
git rev-parse --verify -q "$1" &&
@@ -80,7 +80,7 @@ case "$1" in
mb=$(git-merge-base "$2" "$3")
case "$mb,$2" in
"$2,$mb") info "Update is fast-forward" ;;
- *) deny >/dev/null "This is not a fast-forward update." ;;
+ *) noff=y; info "This is not a fast-forward update.";;
esac
fi
;;
@@ -98,8 +98,9 @@ info "The user is: '$username'"
if [ -f "$allowed_users_file" ]; then
rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
while read head_pattern user_patterns; do
- matchlen=$(expr "$1" : "$head_pattern")
- if [ "$matchlen" == "${#1}" ]; then
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ allow_noff=$(expr substr "$head_pattern" 1 1)
+ if [ "$matchlen" = "${#1}" -a \( -z "$noff" -o "$allow_noff" = '+' \) ]; then
info "Found matching head pattern: '$head_pattern'"
for user_pattern in $user_patterns; do
info "Checking user: '$username' against pattern: '$user_pattern'"
@@ -127,8 +128,9 @@ info "'$groups'"
if [ -f "$allowed_groups_file" ]; then
rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
while read head_pattern group_patterns; do
- matchlen=$(expr "$1" : "$head_pattern")
- if [ "$matchlen" == "${#1}" ]; then
+ matchlen=$(expr "$1" : "${head_pattern#+}")
+ allow_noff=$(expr substr "$head_pattern" 1 1)
+ if [ "$matchlen" = "${#1}" -a \( -z "$noff" -o "$allow_noff" = '+' \) ]; then
info "Found matching head pattern: '$head_pattern'"
for group_pattern in $group_patterns; do
for groupname in $groups; do
@@ -159,6 +161,7 @@ allowed-groups, to describe which heads can be pushed into by
whom. The format of each file would look like this:
refs/heads/master junio
+ +refs/heads/pu junio
refs/heads/cogito$ pasky
refs/heads/bw/.* linus
refs/heads/tmp/.* .*
@@ -166,7 +169,8 @@ whom. The format of each file would look like this:
With this, Linus can push or create "bw/penguin" or "bw/zebra"
or "bw/panda" branches, Pasky can do only "cogito", and JC can
-do master branch and make versioned tags. And anybody can do
-tmp/blah branches.
+do master and pu branches and make versioned tags. And anybody
+can do tmp/blah branches. The '+' sign at the pu record means
+that JC can make non-fast-forward pushes on it.
------------
--
1.5.6
^ permalink raw reply related
* Re: git-fetch remote tag to local branch fails
From: Klas Lindberg @ 2008-06-25 8:50 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8aa486160806240911p49d7bcb8q82a8d68c51206543@mail.gmail.com>
>> I am looking into the possibility of writing a tool that handles
>> configurations of trees.
>
> Maybe you should be using the plumbing commands.
Yes. It looks like it.
>> For instance, I want the tool to be able to
>> consume some version of a configuration and create, update or reset
>> branches in other trees accordingly.
>
> What are the "other trees"?
One tree tracks a configuration file that just contains specs for
other trees. The idea is something like this: Given a refspec on the
configuration tree, git-view the configuration file and use the
contained refspecs to clone/pull/fetch/reset/whatever a bunch of other
trees.
Note that I'm not trying to solve the problem addressed by the
submodules system in git; I need configuration management.
> Maybe you want to keep your local branches up to date with respect
> their tracking branch?
Well yes, but that is only half of it. One of the scenarios I'm
pondering is this: A user wants to take an old configuration based on
tags and try some use case that breaks a newer configuration. After
the checkout, the working trees will not be "on" any branches (what's
the word for that?). Unfortunately, most people seem to think that
everything in a VCS happens on a branch. A lot of people will
incorrectly assume that they are still on their "working branch"
because they didn't check out a different branch! They checked out a
tag and, like myself, have muddy ideas about what that actually means
in relation to branches. I'd prefer to not have to tell them to try
git-lost-found on a 40 different trees to recover commits that they
made on non-branches.
I'll have to think more about this. It's not a functionality
shortcoming, but a UI one.
> I don't see the point updating a branch with a tag, but you can make a
> tool to update a branch with a tag, see for example
> contrib/examples/git-fetch.sh.
Thank you. I'll have a look at that, but after our conversation I
think I was mentally stuck in the land of some other VCS. I know
perfectly well that a tag is not just a marker along some branch, but
I realize now that I was thinking of it as if it was.
/Klas
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Jakub Narebski @ 2008-06-25 8:58 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, Brandon Casey, David Jeske, Boaz Harrosh, git
In-Reply-To: <20080625022610.GB20361@mit.edu>
On Wed, 25 Jun 2008, Theodore Tso wrote:
> The reason why I've been thinking that I should change my shell script
> from:
>
> git checkout integration
> git reset --hard <foo>
>
> to:
>
> git update-ref ref/heads/integration HEAD
> git checkout integration
Hmmmm.... Wouldn't it be easier on fingers to use
git reset --soft integration
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Boaz Harrosh @ 2008-06-25 8:57 UTC (permalink / raw)
To: Jakub Narebski
Cc: David Jeske, git, Brandon Casey, Theodore Tso, Junio C Hamano
In-Reply-To: <m31w2mlki4.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Boaz Harrosh <bharrosh@panasas.com> writes:
>
>
>> Sorry
>> git-reset --clean -f/-n for removing local changes
>> git reset --hard for moving HEAD on a clean tree only
>
> Wouldn't "git reset <commit-ish>" be enough then? It modifies where
> current branch points to (as opposed to git-checkout modifying what is
> the current branch), and it modifies index. What it doesn't modify is
> working directory, but it is clean already.
>
Does not work. only --hard will do the job. The working directory is not
touched and if you'll do a git-diff you'll see the diff between old-head
to new-head. But what I want is to start-hack or merge on new-head.
> So the solution is: don't use `--hard'.
>
the closest to git reset --hard that I can think of is:
Lets say I have
$ git-branch -a
* mybranch
remote/master
I can
$ git reset --hard remote/master
Or I can
$ git-checkout -b temp_mybranch remote/master
$ git-branch -M temp_mybranch mybranch
The second will complain if I have local changes.
I have just written 2 scripts. One "git-reset" that
will filter out --hard before calling the original.
Second "git-reset--hard" that will do the above.
Stupid me no more. It will not happen to me again.
Just those poor new users out there, I guess you have to
fall off your bike at least once.
Boaz
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Jakub Narebski @ 2008-06-25 9:10 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Santi Béjar, git
In-Reply-To: <33f4f4d70806250150q41f09764m4ae0cc1cd6e15e30@mail.gmail.com>
"Klas Lindberg" <klas.lindberg@gmail.com> writes:
> Note that I'm not trying to solve the problem addressed by the
> submodules system in git; I need configuration management.
Why not use one of existing tools (see InterfacesFrontendsAndTools
page on Git Wiki, http://git.or.cz/gitwiki/), like IsiSetup, or
etckeeper?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Boaz Harrosh @ 2008-06-25 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Walter, git, jeske
In-Reply-To: <7vwskea2ik.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Steven Walter <stevenrwalter@gmail.com> writes:
>
>> @@ -225,6 +243,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
>> if (reset_type == HARD && is_bare_repository())
>> die("hard reset makes no sense in a bare repository");
>>
>> + if (reset_type == HARD && !force && index_is_dirty()) {
>> + die("Uncommitted changes; re-run with -f to trash them");
>> + }
>> +
>
> Please don't. With your change, does the testsuite even pass?
>
> "reset --hard" has *ALWAYS* meant to be destructive --- discarding
> potential local cruft is the whole point of the operation.
>
I was under the impression that --hard means working-directory-also
as opposed to tree-and-index-only. Nothing to do with
destructive-discarding. If it is then something is missing.
I need 2 distinct functions. You combine to functions under
one command.
> Learn the lingo, and get over it.
>
I did lern the lingo and got bitten. I wanted to do one thing
also got the other one.
there is:
git-reset --clean - destructive-discarding any local changes
git-reset --hard - move tree index and working directory to new head
How can I separate between them, Please
Boaz
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Junio C Hamano @ 2008-06-25 9:14 UTC (permalink / raw)
To: Jakub Narebski
Cc: Theodore Tso, Brandon Casey, David Jeske, Boaz Harrosh, git
In-Reply-To: <200806251058.54319.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Wed, 25 Jun 2008, Theodore Tso wrote:
>
>> The reason why I've been thinking that I should change my shell script
>> from:
>>
>> git checkout integration
>> git reset --hard <foo>
>>
>> to:
>>
>> git update-ref ref/heads/integration HEAD
>> git checkout integration
>
> Hmmmm.... Wouldn't it be easier on fingers to use
>
> git reset --soft integration
That does not do anything close to what Ted is doing, does it?
Anyway, here is how I conclude my git day:
git checkout next
... merge more and test
... be happy that next is in very good shape ;-)
git branch -f pu
git checkout pu
git merge ... merge other topics to rebuild pu
git merge ...
...
which is probably a bit less error prone then update-ref, if you type from
the command line like I do.
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 9:23 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Steven Walter, git, jeske
In-Reply-To: <48620C1A.6000509@panasas.com>
Boaz Harrosh <bharrosh@panasas.com> writes:
> Junio C Hamano wrote:
>
>> "reset --hard" has *ALWAYS* meant to be destructive --- discarding
>> potential local cruft is the whole point of the operation.
>
> I was under the impression that --hard means working-directory-also
> as opposed to tree-and-index-only. Nothing to do with
> destructive-discarding.
Then you should revise your impression, as it is simply *WRONG*. When
I say something about history of git, I know what I am talking about ;-)
Reset has been about nuking local changes from the very beginning. That
is why it removes MERGE_HEAD, rr-cache/MERGE_RR as well as removing
conflicted stages in the index and reverts local changes from the worktree.
It is "my worktree state is a mess, and I cannot even describe nor care
which paths are dirty --- just get rid of the local changes so that I can
start working cleanly from a checkout of HEAD".
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Jakub Narebski @ 2008-06-25 9:30 UTC (permalink / raw)
To: David Jeske; +Cc: Theodore Tso, git
In-Reply-To: <10634.0258535512$1214372002@news.gmane.org>
"David Jeske" <jeske@willowmail.com> writes:
> -- Theodore Tso wrote:
> > ???
> > >
> > > (a) safely "share" every DAG, branch, and tag data in their
> > > repository to a well-connected server, into an established
> > > namespace, while only changing branches and tags in their
> > > namespace. This will allow all users to see the changes of other
> > > users, without needing direct access to their trees (which are
> > > inaccessible behind firewalls). [1]
> >
> > Right, so thats github and/or git.or.cz. Each user gets his/her own
> > repository, but thats a very minor change. Not a big deal.
>
> ...most notably, all their DAGs in a single repository to save space
> is important. Thousands of copies of thousands of repositories adds
> up. Especially when most of the users who want to commit something
> probably commit <1-10k of unique stuff. Seems pretty easy to change
> though. git.or.cz and github will both be wanting this eventually.
repo.or.cz has support for forks, i.e. sharing object database (for
old objects) via alternates, although it is not "common object
database" (as in, for example, $GIT_DIR/objects symlinked to single
common parent repository)
GitHub has also some support for "forks", but as it is closed source I
don't think anybody knows how it is done.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-25 9:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5ggipuw.fsf@gitster.siamese.dyndns.org>
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.
It already is beginning to become clear what 1.6.0 will look like. What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements. But bigger changes will be:
* MinGW will be in.
* /usr/bin/git-cat-file is no more. The bulk of the git commands will
move to /usr/libexec/git-core/ or somesuch.
* git-merge will be rewritten in C.
* default pack and idx versions will be updated as scheduled for some
time ago.
----------------------------------------------------------------
[New Topics]
* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
- Migrate git-blame to parse-option partially.
- parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
- parse-opt: fake short strings for callers to believe in.
- parse-opt: do not pring errors on unknown options, return -2
intead.
- parse-opt: create parse_options_step.
- parse-opt: Export a non NORETURN usage dumper.
- parse-opt: have parse_options_{start,end}.
----------------------------------------------------------------
[Will merge to master soon]
* lw/gitweb (Thu Jun 19 22:03:21 2008 +0200) 1 commit
+ gitweb: standarize HTTP status codes
* lt/config-fsync (Wed Jun 18 15:18:44 2008 -0700) 4 commits
+ Add config option to enable 'fsync()' of object files
+ Split up default "i18n" and "branch" config parsing into helper
routines
+ Split up default "user" config parsing into helper routine
+ Split up default "core" config parsing into helper routine
* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
+ Keep some git-* programs in $(bindir)
+ Move all dashed-form commands to libexecdir
Scheduled for 1.6.0. We'll leave server-side programs in $(bindir)
so that ssh clients can ask for "git-program" and find them on the $PATH.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
* sr/tests (Sun Jun 8 16:04:35 2008 +0200) 3 commits
+ Hook up the result aggregation in the test makefile.
+ A simple script to parse the results from the testcases
+ Modify test-lib.sh to output stats to t/test-results/*
* jh/clone-packed-refs (Sun Jun 15 16:06:16 2008 +0200) 4 commits
+ Teach "git clone" to pack refs
+ Prepare testsuite for a "git clone" that packs refs
+ Move pack_refs() and friends into libgit
+ Incorporate fetched packs in future object traversal
This is useful when cloning from a repository with insanely large number
of refs.
* lw/perlish (Thu Jun 19 22:32:49 2008 +0200) 2 commits
+ Git.pm: add test suite
+ t/test-lib.sh: add test_external and test_external_without_stderr
Beginning of regression tests for Perl part of the system.
----------------------------------------------------------------
[Actively Cooking]
* mv/merge-in-c (Sat Jun 21 19:15:35 2008 +0200) 12 commits
- Add new test case to ensure git-merge reduces octopus parents when
possible
- Build in merge
- Introduce reduce_heads()
- Introduce get_merge_bases_many()
- Add new test to ensure git-merge handles more than 25 refs.
- Introduce get_octopus_merge_bases() in commit.c
- git-fmt-merge-msg: make it usable from other builtins
- Move read_cache_unmerged() to read-cache.c
- Add new test to ensure git-merge handles pull.twohead and
pull.octopus
- Move parse-options's skip_prefix() to git-compat-util.h
- Move commit_list_count() to commit.c
- Move split_cmdline() to alias.c
I dropped the change to parseopt in this series and fixed up the caller.
* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
+ Prepare execv_git_cmd() for removal of builtins from the
filesystem
+ git-shell: accept "git foo" form
We do not plan to remove git-foo form completely from the filesystem at
this point, but git-shell may need to be updated.
* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
+ Eliminate an unnecessary chdir("..")
+ Add support for GIT_CEILING_DIRECTORIES
+ Fold test-absolute-path into test-path-utils
+ Implement normalize_absolute_path
* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
- rerere.autoupdate
- t4200: fix rerere test
- rerere: remove dubious "tail_optimization"
- git-rerere: detect unparsable conflicts
- rerere: rerere_created_at() and has_resolution() abstraction
* sb/rebase (Sun Jun 22 01:55:50 2008 +0200) 2 commits
+ t3404: stricter tests for git-rebase--interactive
+ api-builtin.txt: update and fix typo
* sb/maint-rebase (Sun Jun 22 16:07:02 2008 +0200) 1 commit
+ git-rebase.sh: Add check if rebase is in progress
----------------------------------------------------------------
[Graduated to "master"]
----------------------------------------------------------------
[On Hold]
* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
+ Remove the use of '--' in merge program invocation
Waiting for success reports from people who use various backends.
* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 39 commits
- compat/pread.c: Add a forward declaration to fix a warning
- Windows: Fix ntohl() related warnings about printf formatting
- Windows: TMP and TEMP environment variables specify a temporary
directory.
- Windows: Make 'git help -a' work.
- Windows: Work around an oddity when a pipe with no reader is
written to.
- Windows: Make the pager work.
- When installing, be prepared that template_dir may be relative.
- Windows: Use a relative default template_dir and ETC_GITCONFIG
- Windows: Compute the fallback for exec_path from the program
invocation.
- Turn builtin_exec_path into a function.
- Windows: Use a customized struct stat that also has the st_blocks
member.
- Windows: Add a custom implementation for utime().
- Windows: Add a new lstat and fstat implementation based on Win32
API.
- Windows: Implement a custom spawnve().
- Windows: Implement wrappers for gethostbyname(), socket(), and
connect().
- Windows: Work around incompatible sort and find.
- Windows: Implement asynchronous functions as threads.
- Windows: Disambiguate DOS style paths from SSH URLs.
- Windows: A rudimentary poll() emulation.
- Windows: Change the name of hook scripts to make them not
executable.
- Windows: Implement start_command().
- Windows: A pipe() replacement whose ends are not inherited to
children.
- Windows: Wrap execve so that shell scripts can be invoked.
- Windows: Implement setitimer() and sigaction().
- Windows: Fix PRIuMAX definition.
- Windows: Implement gettimeofday().
- Make my_mktime() public and rename it to tm_to_time_t()
- Windows: Work around misbehaved rename().
- Windows: always chmod(, 0666) before unlink().
- Windows: A minimal implemention of getpwuid().
- Windows: Implement a wrapper of the open() function.
- Windows: Strip ".exe" from the program name.
- Windows: Handle absolute paths in
safe_create_leading_directories().
- Windows: Treat Windows style path names.
- setup.c: Prepare for Windows directory separators.
- Windows: Use the Windows style PATH separator ';'.
- Add target architecture MinGW.
- Compile some programs only conditionally.
- Add compat/regex.[ch] and compat/fnmatch.[ch].
No explanation is necessary ;-). The series is probably 'next' worthy
as-is, except that template renaming hack won't be needed anymore.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* jc/reflog-expire (Sun Jun 15 23:48:46 2008 -0700) 1 commit
- Per-ref reflog expiry configuration
Perhaps a good foundation for optionally unexpirable stash. As 1.6.0 will
be a good time to make backward incompatible changes, we might make expiry
period of stash 'never' in new repositories. Needs a concensus.
* jc/merge-theirs (Fri Jun 20 00:17:59 2008 -0700) 2 commits
- git-merge-recursive-{ours,theirs}
- git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends may need to change, though.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
+ git-blame --reverse
+ builtin-blame.c: allow more than 16 parents
+ builtin-blame.c: move prepare_final() into a separate function.
+ rev-list --children
+ revision traversal: --children option
The blame that finds where each line in the original lines moved to. This
may help a GSoC project that wants to gather statistical overview of the
history. The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).
The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.
----------------------------------------------------------------
[Dropped for now]
* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
. Introduce fast forward option only
. Head reduction before selecting merge strategy
. Restructure git-merge.sh
. Introduce -ff=<fast forward option>
. New merge tests
. Documentation for joining more than two histories
This will interfere with Miklos's rewrite of merge to C.
* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
. Use perl instead of tac
. Fix t3404 assumption that `wc -l` does not use whitespace.
. rebase -i: Use : in expr command instead of match.
. rebase -i: update the implementation of 'mark' command
. Add option --preserve-tags
. Teach rebase interactive the tag command
. Add option --first-parent
. Do rebase with preserve merges with advanced TODO list
. Select all lines with fake-editor
. Unify the length of $SHORT* and the commits in the TODO list
. Teach rebase interactive the merge command
. Move redo merge code in a function
. Teach rebase interactive the reset command
. Teach rebase interactive the mark command
. Move cleanup code into it's own function
. Don't append default merge message to -m message
. fake-editor: output TODO list if unchanged
* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
. WIP: rethink replay merge
. Start using replay-tree merge in cherry-pick
. revert/cherry-pick: start refactoring call to merge_recursive
This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
Just my toy at this moment.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
. "git push": tellme-more protocol extension
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2008-06-25 9:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vej6oipea.fsf@gitster.siamese.dyndns.org>
We'd need a maint release soon to push out the mkstemp() breakage but not
tonight. There are a handful changes that are in 'master' and 'next' that
need backport/backmerge before 1.5.6.1 happens.
* The 'maint' branch has these fixes since the last announcement.
Jan Krüger (1):
git-svn: make rebuild respect rewriteRoot option
Patrick Higgins (1):
Workaround for AIX mkstemp()
* The 'master' branch has these since the last announcement
in addition to the above.
Jeff King (1):
clone: create intermediate directories of destination repo
Junio C Hamano (2):
pre-rebase hook update
Ship sample hooks with .sample suffix
Michele Ballabio (1):
t9301-fast-export.sh: Remove debug line
Nicolas Pitre (8):
call init_pack_revindex() lazily
implement some resilience against pack corruptions
test case for pack resilience against corruptions
refactor pack structure allocation
optimize verify-pack a bit
move show_pack_info() where it belongs
verify-pack: check packed object CRC when using index version 2
verify-pack: test for detection of index v2 object CRC mismatch
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Boaz Harrosh @ 2008-06-25 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Walter, git, jeske
In-Reply-To: <7vr6al3m24.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Boaz Harrosh <bharrosh@panasas.com> writes:
>
>> Junio C Hamano wrote:
>>
>>> "reset --hard" has *ALWAYS* meant to be destructive --- discarding
>>> potential local cruft is the whole point of the operation.
>> I was under the impression that --hard means working-directory-also
>> as opposed to tree-and-index-only. Nothing to do with
>> destructive-discarding.
>
> Then you should revise your impression, as it is simply *WRONG*. When
> I say something about history of git, I know what I am talking about ;-)
>
> Reset has been about nuking local changes from the very beginning. That
> is why it removes MERGE_HEAD, rr-cache/MERGE_RR as well as removing
> conflicted stages in the index and reverts local changes from the worktree.
>
> It is "my worktree state is a mess, and I cannot even describe nor care
> which paths are dirty --- just get rid of the local changes so that I can
> start working cleanly from a checkout of HEAD".
OK Thanks, I see.
I have made myself that git-move-head script that uses checkouts and
renames so I guess I'm happy. I used to use the --hard as a shortcut.
Boaz
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Johannes Schindelin @ 2008-06-25 10:16 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <48620C1A.6000509@panasas.com>
Hi,
just to add to Junio's comments:
On Wed, 25 Jun 2008, Boaz Harrosh wrote:
> Junio C Hamano wrote:
> > Steven Walter <stevenrwalter@gmail.com> writes:
> >
> >> @@ -225,6 +243,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
> >> if (reset_type == HARD && is_bare_repository())
> >> die("hard reset makes no sense in a bare repository");
> >>
> >> + if (reset_type == HARD && !force && index_is_dirty()) {
> >> + die("Uncommitted changes; re-run with -f to trash them");
> >> + }
> >> +
> >
> > Please don't. With your change, does the testsuite even pass?
> >
> > "reset --hard" has *ALWAYS* meant to be destructive --- discarding
> > potential local cruft is the whole point of the operation.
> >
>
> I was under the impression that --hard means working-directory-also
> as opposed to tree-and-index-only. Nothing to do with
> destructive-discarding.
But "reset" _means_ to discard something.
Frankly, we could introduce "git reset --hard --force --really
--really-i-mean-it --do-reset-the-fscking-working-directory-NOW", but I do
not think that it makes sense.
If you want to reset the working directory, you want to reset the working
directory. If you wanted to save the changes somewhere, you should have
done that. We have enough ways to do that.
> > Learn the lingo, and get over it.
>
> I did lern the lingo and got bitten.
Apparently not. So again, "reset --hard" means to reset HEAD, index and
working directory to the revision you pass (defaulting to the HEAD).
The fact that you do not lose the information which used to be HEAD, is
just a side-effect of Git storing all the revisions in one big graph. It
is _not_ implied by "reset", which, as I pointed out, means "re-set".
> there is:
> git-reset --clean - destructive-discarding any local changes
What would be a "nondestructive-discarding", /me wonders.
> git-reset --hard - move tree index and working directory to new head
That is not "git reset --hard".
"move" to a new head is called "switching branches" in Git lingo (and BTW
in many other SCM lingos, too, so you might just as well get used to it),
and it is another command: "git checkout <branch>".
Incidentally, a friend just told me that "checkout" is everything but
intuitive, and he would have preferred "git branch switch <branch>", but
then settled for my proposed "git branch --switch <branch>", which I did
not have time to implement yet, unfortunately.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Matthias Kestenholz @ 2008-06-25 10:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boaz Harrosh, Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <alpine.DEB.1.00.0806251109380.9925@racer>
On Wed, 2008-06-25 at 11:16 +0100, Johannes Schindelin wrote:
> Incidentally, a friend just told me that "checkout" is everything but
> intuitive, and he would have preferred "git branch switch <branch>", but
> then settled for my proposed "git branch --switch <branch>", which I did
> not have time to implement yet, unfortunately.
But why? I don't want to 'branch', I want to 'checkout' another branch,
which incidentally matches the git command I need to use to achieve
that.
Matthias
^ permalink raw reply
* [PATCH] git-gui: Don't select the wrong file if the last listed file is staged.
From: Abhijit Menon-Sen @ 2008-06-25 10:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Johannes Sixt
In-Reply-To: <1213308730-12707-1-git-send-email-ams@toroid.org>
Johannes Sixt noticed that if the last file in the list was staged, my
earlier patch would display the diff for the penultimate file, but show
the file _before_ that as being selected.
This was due to my misunderstanding the lno argument to show_diff.
This patch fixes the problem: lno is not decremented in the special case
to handle the last item in the list (though we still need to use $lno-1
to find the right path for the next diff).
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
git-gui/git-gui.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 23d7dfe..fe4a4c2 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1806,14 +1806,16 @@ proc toggle_or_diff {w x y} {
} else {
global next_diff_p next_diff_w next_diff_i
+ set next_diff_w $w
+
if {$i < $ll} {
set i [expr {$i + 1}]
+ set next_diff_i $i
} else {
+ set next_diff_i $i
set i [expr {$i - 1}]
}
- set next_diff_i $i
- set next_diff_w $w
set next_diff_p [lindex $file_lists($w) $i]
if {$next_diff_p ne {} && $current_diff_path ne {}} {
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Johannes Sixt @ 2008-06-25 10:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boaz Harrosh, Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <alpine.DEB.1.00.0806251109380.9925@racer>
Johannes Schindelin schrieb:
> Incidentally, a friend just told me that "checkout" is everything but
> intuitive, and he would have preferred "git branch switch <branch>", but
> then settled for my proposed "git branch --switch <branch>", which I did
> not have time to implement yet, unfortunately.
$ git config alias.switch checkout
$ git switch topic
Hm? Notice that the command even reports back:
Switched to branch "topic"
^^^^^^^^
-- Hannes
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Anton Gladkov @ 2008-06-25 10:46 UTC (permalink / raw)
To: Matthias Kestenholz
Cc: Johannes Schindelin, Boaz Harrosh, Junio C Hamano, Steven Walter,
git@vger.kernel.org, jeske@google.com
In-Reply-To: <1214389498.6634.10.camel@localhost>
On Wed, Jun 25, 2008 at 02:24:58PM +0400, Matthias Kestenholz wrote:
> On Wed, 2008-06-25 at 11:16 +0100, Johannes Schindelin wrote:
> > Incidentally, a friend just told me that "checkout" is everything but
> > intuitive, and he would have preferred "git branch switch <branch>", but
> > then settled for my proposed "git branch --switch <branch>", which I did
> > not have time to implement yet, unfortunately.
>
> But why? I don't want to 'branch', I want to 'checkout' another branch,
> which incidentally matches the git command I need to use to achieve
> that.
Because 'checkout' in other SCMs like CVS or SVN means 'get latest data from
repo', i.e. it acts like 'pull' or 'fetch' in git.
And 'branch' means branch manipulation: creating, deleting, switching...
--
Best regards,
Anton
mailto:agladkov@parallels.com
^ permalink raw reply
* Re: [PATCH] git-gui: Don't select the wrong file if the last listed file is staged.
From: Johannes Sixt @ 2008-06-25 10:49 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git, Shawn O. Pearce
In-Reply-To: <20080625103650.GA20492@toroid.org>
Abhijit Menon-Sen schrieb:
> Johannes Sixt noticed that if the last file in the list was staged, my
> earlier patch would display the diff for the penultimate file, but show
> the file _before_ that as being selected.
>
> This was due to my misunderstanding the lno argument to show_diff.
>
> This patch fixes the problem: lno is not decremented in the special case
> to handle the last item in the list (though we still need to use $lno-1
> to find the right path for the next diff).
Thanks. It works here, too:
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
-- Hannes
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Johannes Schindelin @ 2008-06-25 12:33 UTC (permalink / raw)
To: Anton Gladkov
Cc: Matthias Kestenholz, Boaz Harrosh, Junio C Hamano, Steven Walter,
git@vger.kernel.org, jeske@google.com
In-Reply-To: <20080625104605.GA10322@atn.sw.ru>
Hi,
On Wed, 25 Jun 2008, Anton Gladkov wrote:
> On Wed, Jun 25, 2008 at 02:24:58PM +0400, Matthias Kestenholz wrote:
> > On Wed, 2008-06-25 at 11:16 +0100, Johannes Schindelin wrote:
> > > Incidentally, a friend just told me that "checkout" is everything but
> > > intuitive, and he would have preferred "git branch switch <branch>", but
> > > then settled for my proposed "git branch --switch <branch>", which I did
> > > not have time to implement yet, unfortunately.
> >
> > But why? I don't want to 'branch', I want to 'checkout' another branch,
> > which incidentally matches the git command I need to use to achieve
> > that.
>
> Because 'checkout' in other SCMs like CVS or SVN means 'get latest data
> from repo', i.e. it acts like 'pull' or 'fetch' in git. And 'branch'
> means branch manipulation: creating, deleting, switching...
Actually, I don't find this a good reason at all. The fact that other
SCMs bastardized a term to mean something it clearly does not mean, is
irrelevant here.
The thing is: if we say "let's switch branches", what command would spring
to mind to a (non-CVS-braindamaged) user? Exactly: "git branch". That is
the command that should do something with branches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Johannes Schindelin @ 2008-06-25 12:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Boaz Harrosh, Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <486220CE.3070103@viscovery.net>
Hi,
On Wed, 25 Jun 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > Incidentally, a friend just told me that "checkout" is everything but
> > intuitive, and he would have preferred "git branch switch <branch>", but
> > then settled for my proposed "git branch --switch <branch>", which I did
> > not have time to implement yet, unfortunately.
>
> $ git config alias.switch checkout
> $ git switch topic
>
> Hm? Notice that the command even reports back:
>
> Switched to branch "topic"
> ^^^^^^^^
Nice. And now my friend says "why does this braindamaged Git not have
that command by _default_? Hmm? It is _just as braindamaged_ as CVS!"
And I would not have anything reasonable for my defense.
Because Git _should_ have an intuitive command to switch branches by
default. "git checkout" just does not fly, especially given that it can
be used to revert single files (which "git revert" should know how to, but
does not, see
http://mid.gmane.org/7vlk8wshii.fsf@gitster.siamese.dyndns.org).
I _do_ see a cause of confusion here, _even_ if I know Git pretty well.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection
From: Theodore Tso @ 2008-06-25 13:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce,
しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vy74u5bkk.fsf@gitster.siamese.dyndns.org>
On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
> Ok, let's map this out seriously.
>
> * 1.6.0 will install the server-side programs in $(bindir) so that
> people coming over ssh will find them on the $PATH
>
> * In 1.6.0 (and 1.5.6.1), we will change "git daemon" to accept both
> "git-program" and "git program" forms. When the spaced form is used, it
> will behave as if the dashed form is requested. This is a prerequisite
> for client side change to start asking for "git program".
>
> * In the near future, there will no client-side change. "git-program"
> will be asked for.
>
> * 6 months after 1.6.0 ships, hopefully all the deployed server side will
> be running that version or newer. Client side will start asking for
> "git program" by default, but we can still override with --upload-pack
> and friends.
>
> * 12 months after client side changes, everybody will be running that
> version or newer. We stop installing the server side programs in
> $(bindir) but people coming over ssh will be asking for "git program"
> and "git" will be on the $PATH so there is no issue.
>
> The above 6 and 12 are yanked out of thin air and I am of course open to
> tweaking them, but I think the above order of events would be workable.
Is that really 6 and 12 months, or "6/12 months or at the next major
release boundary, whichever is later". i.e., would make some of these
changes as part of a minor dot release, such as having the client side
change what it starts asking for in 1.6.3 or some such? Presumably
the earliest that change would happen is 1.7, and the earliest to make
the server side installation changes is 1.8, right? Or did you really
mean a hard 6/12 months, regardless of release cycle issues?
- Ted
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Matthieu Moy @ 2008-06-25 12:20 UTC (permalink / raw)
To: David Jeske; +Cc: Brandon Casey, git
In-Reply-To: <willow-jeske-01l5xqJDFEDjCftd>
"David Jeske" <jeske@google.com> writes:
> - standardize all the potentially destructive operations (after gc) on "-f /
> --force" to override
Depending on the definition of "potentially destructive", most
commands are "potentially destructive".
git pull loses the point where the branch used to point when the
reflog expires.
git add loses the old content of the index.
...
And adding too many --force options removes its real value. Many
people type "rm -fr" any time they just want "rm", just because they
were annoyed by the multiple interactive confirmations of plain "rm"
(if aliased to "rm -i"). Asking people to type --force all the time
make one fingers type --force mechanically, and removes all its value.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Ian Hilt @ 2008-06-25 13:19 UTC (permalink / raw)
To: Boaz Harrosh; +Cc: Junio C Hamano, Steven Walter, git, jeske
In-Reply-To: <48620C1A.6000509@panasas.com>
On Wed, 25 Jun 2008 at 12:12pm +0300, Boaz Harrosh wrote:
> Junio C Hamano wrote:
> > Learn the lingo, and get over it.
> >
>
> I did lern the lingo and got bitten. I wanted to do one thing
> also got the other one.
Something that I think has not been emphasized enough for whatever
reason is how _easy_ it is to test out git commands. For example, if
you have a really_important_repo that you don't want to screw up, but
you need to do a potentially destructive thing to it, just do,
$ cp -r /path/to/really_important_repo ~/test
$ cd ~/test && git destructive
and you find out whether your mental concept of what "git destructive"
does is correct or not without possibly losing your work.
--
Ian Hilt
Ian.Hilt (at) gmx.com
GnuPG key: 0x4AFC1EE3
^ permalink raw reply
* Errors building git-1.5.6 from source on Mac OS X 10.4.11
From: Ifejinelo Onyiah @ 2008-06-25 13:20 UTC (permalink / raw)
To: git
Hi,
I have made several attempts to build Git (version 1.5.6) on my Mac OS
X 10.4.11 (Tiger) but have had little luck. At the time of my last try
(2008-06-25 11:08) there were no pre-built binaries for Tiger on the
Git home page. I downloaded the source file from home page and issued
the following commands:
% tar -xzf git-1.5.6.tar.gz
% cd git-1.5.6
% ./configure --prefix=/Users/io1/Applications/Git/1.5.6
% make
They all run fine but when I issue the make test command, it dies at
the following:
% make test
... TRUNCATED OUTPUT ...
*** t2004-checkout-cache-temp.sh ***
* FAIL 1: preparation
mkdir asubdir &&
echo tree1path0 >path0 &&
echo tree1path1 >path1 &&
echo tree1path3 >path3 &&
echo tree1path4 >path4 &&
echo tree1asubdir/path5 >asubdir/path5 &&
git update-index --add path0 path1 path3 path4 asubdir/path5 &&
t1=$(git write-tree) &&
rm -f path* .merge_* out .git/index &&
echo tree2path0 >path0 &&
echo tree2path1 >path1 &&
echo tree2path2 >path2 &&
echo tree2path4 >path4 &&
git update-index --add path0 path1 path2 path4 &&
t2=$(git write-tree) &&
rm -f path* .merge_* out .git/index &&
echo tree2path0 >path0 &&
echo tree3path1 >path1 &&
echo tree3path2 >path2 &&
echo tree3path3 >path3 &&
git update-index --add path0 path1 path2 path3 &&
t3=$(git write-tree)
* ok 2: checkout one stage 0 to temporary file
* ok 3: checkout all stage 0 to temporary files
* ok 4: prepare 3-way merge
* FAIL 5: checkout one stage 2 to temporary file
rm -f path* .merge_* out &&
git checkout-index --stage=2 --temp -- path1 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
p=$(cut "-d " -f1 out) &&
test -f $p &&
test $(cat $p) = tree2path1
* FAIL 6: checkout all stage 2 to temporary files
rm -f path* .merge_* out &&
git checkout-index --all --stage=2 --temp >out &&
test $(wc -l <out) = 3 &&
for f in path1 path2 path4
do
test $(grep $f out | cut "-d " -f2) = $f &&
p=$(grep $f out | cut "-d " -f1) &&
test -f $p &&
test $(cat $p) = tree2$f
done
* ok 7: checkout all stages/one file to nothing
* FAIL 8: checkout all stages/one file to temporary files
rm -f path* .merge_* out &&
git checkout-index --stage=all --temp -- path1 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path1 &&
cut "-d " -f1 out | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s1) = tree1path1 &&
test $(cat $s2) = tree2path1 &&
test $(cat $s3) = tree3path1)
* FAIL 9: checkout some stages/one file to temporary files
rm -f path* .merge_* out &&
git checkout-index --stage=all --temp -- path2 >out &&
test $(wc -l <out) = 1 &&
test $(cut "-d " -f2 out) = path2 &&
cut "-d " -f1 out | (read s1 s2 s3 &&
test $s1 = . &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s2) = tree2path2 &&
test $(cat $s3) = tree3path2)
* FAIL 10: checkout all stages/all files to temporary files
rm -f path* .merge_* out &&
git checkout-index -a --stage=all --temp >out &&
test $(wc -l <out) = 5
* ok 11: -- path0: no entry
* FAIL 12: -- path1: all 3 stages
test $(grep path1 out | cut "-d " -f2) = path1 &&
grep path1 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s1) = tree1path1 &&
test $(cat $s2) = tree2path1 &&
test $(cat $s3) = tree3path1)
* FAIL 13: -- path2: no stage 1, have stage 2 and 3
test $(grep path2 out | cut "-d " -f2) = path2 &&
grep path2 out | cut "-d " -f1 | (read s1 s2 s3 &&
test $s1 = . &&
test -f $s2 &&
test -f $s3 &&
test $(cat $s2) = tree2path2 &&
test $(cat $s3) = tree3path2)
* FAIL 14: -- path3: no stage 2, have stage 1 and 3
test $(grep path3 out | cut "-d " -f2) = path3 &&
grep path3 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test $s2 = . &&
test -f $s3 &&
test $(cat $s1) = tree1path3 &&
test $(cat $s3) = tree3path3)
* FAIL 15: -- path4: no stage 3, have stage 1 and 3
test $(grep path4 out | cut "-d " -f2) = path4 &&
grep path4 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test -f $s2 &&
test $s3 = . &&
test $(cat $s1) = tree1path4 &&
test $(cat $s2) = tree2path4)
* FAIL 16: -- asubdir/path5: no stage 2 and 3 have stage 1
test $(grep asubdir/path5 out | cut "-d " -f2) = asubdir/path5 &&
grep asubdir/path5 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f $s1 &&
test $s2 = . &&
test $s3 = . &&
test $(cat $s1) = tree1asubdir/path5)
* FAIL 17: checkout --temp within subdir
(cd asubdir &&
git checkout-index -a --stage=all >out &&
test $(wc -l <out) = 1 &&
test $(grep path5 out | cut "-d " -f2) = path5 &&
grep path5 out | cut "-d " -f1 | (read s1 s2 s3 &&
test -f ../$s1 &&
test $s2 = . &&
test $s3 = . &&
test $(cat ../$s1) = tree1asubdir/path5)
)
* ok 18: checkout --temp symlink
* failed 12 among 18 test(s)
make[1]: *** [t2004-checkout-cache-temp.sh] Error 1
make: *** [test] Error 2
%
I have searched the mailing lists and googled around but have yet to
turn up a satisfactory solution. Hence I come to you.
Any assistance will be greatly appreciated.
_____________________________
Ifejinelo Onyiah
Computer Biologist
Genome Dynamics and Evolution Group
Wellcome Trust Sanger Institute
Hinxton
Cambridge CB10 1SA
UK
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Theodore Tso @ 2008-06-25 13:34 UTC (permalink / raw)
To: David Jeske; +Cc: git
On Wed, Jun 25, 2008 at 05:20:49AM -0000, David Jeske wrote:
> The other big one is ACLs in 'well named' repositories, so multiple
> people can safely be allowed to add changes to them, without giving
> them ability to blow away the repository. I can see this isn't the
> way all git users work, but at least a few users working this way
> now with shared push repositories. This is just making it
> 'safer'. Also seems pretty easy to do.
So this isn't true security, since someone determined (or an ingenious
enough fool) can always blow away repository if you allow them to add
changes; they could just add a change which rm's all of the files,
yes? You just want to prevent something stupid.
Well, as long as they don't do non-fast forward updates (i.e., they
never do something like: "git push publish +head:head", or any other
incantation involving a leading '+' in the refspec), they should be
pretty safe. I don't see how they would do any damage just due to
user confusion. So I think git is pretty safe as-is.
> > This is also easy; you just establish remote tracking branches. I
> > have a single shell scripted command, git-get-all, which pulls from
> > all of the repositories I am interested in into various remote
> > tracking branches so while I am disconnected, I can see what other
> > folks have done on their trees.
>
> Yes, so I'd have the same thing, except instead of a remote
> repository, it would be a pattern of the branch namespace, such as
> /origin/users/jeske/*.
And the advantage of using branch namespaces instead of separate
remote repositories is.... ? I don't see any....
> Think about using CVS. user does "cvs up; hack hack hack; cvs commit
> (to server)". In git, this workflow is "git pull; hack; commit;
> hack; commit; git push (to server)". I want those interum "commits"
> to share the changes with the server. I want to change this to "git
> pull; hack; commit-and-share; hack; commit-and-share; git-push (to
> shared branch tag)"
OK, so *why* is it a good idea to ask people to share their
in-progress work? What's the upside? Maybe if the idea is as backup
if people are working from their laptops, and they're about to travel
internationally or some such, but in general, sharing in-progress work
is highly overrated.
The other thing is in your design assumption is that remote
repositories are somehow expensive, when in fact they are very cheap;
use either repo.or.cz or github; they support repo sharing so there
isn't major cost to letting each developer having their own repository
to push to.
So the way I would do things is to simply encourage people to do start
their work by branching off of an up-to-date master branch, but *not*
do any git pulls or git pushes. They can use git commit as necessary
to save interim work, and they do all of this work on a private
branch. When they are done doing their work, they should review the
git commit points and make sure they make sense; in some cases they
may be better off squashing the commits down to a single commit, or
possibly refactoring their work so that each individual commit is
free-standing, so that their series of commits is git-bisectable
(i.e., after each commit the tree will fully compile and fully pass
the project regression test suite).
Once they have done *that*, they make sure the master branch has been
fully updated, and then do a git-rebase on their feature branch so
that it is up-to-date with respect to master, and then they do a full
build and regression test. Then they switch back to the master
branch, and do a "git push publish" --- where <publish> is defined in
.git/config to be something like this:
[remote "publish"]
url = ssh://master.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
push = refs/heads/master:refs/heads/master
This will *only* push the master branch (and not any of the feature
branches), and it will not allow non-fast forward merges. Hence, if
the user screwed up and accidentally made changes to the master branch
(say, an accidental git-rebase while on the master branch, or
something else bone-headed), the git push will fail. This gives you
the safety you desire about not accidentally screwing up the master branch.
And you're done. The only reason why you need a per-user repository
if you want some safety in terms of backups in case the work being
done on the laptop gets destroyed, but you can get that pretty much
for free via git.or.cz or github. I really don't buy the sharing
argument, because if you are in the middle of implementing a feature,
it's generally not useful for others to look at your in-progress work.
> I know that all of what I wrote above seems strange if you don't buy into the
> design assumptions. That it's critical to share a single server-repository,
> that it's critical to have a shared 'well known' branch that only trusts
> clients to add new changes to, etc.. However, these are important.
Yep. And you still haven't justified why it's critical to share a
single server repository. ***Why*** is that important?
And when you have shared push repositories, as long as users don't use
the '+', in practice they can only add new changes. And if you don't
trust them not to use the '+' character in refspecs, are you really
going to trust them not to introduce either bone-headed mistakes into
the code? Or to "git rm" the wrong files, git commit them, and then
merge that into the repository? If all you care about is avoiding the
accidentally stupid user mistakes, then putting in a convenience
default so that "git push publish" always does what you want should be
good enough.
So fundamentally, yeah, I think your primary problem is with the
design assumptions, which haven't been justified at all.
- Ted
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox