* Re: keeping remote repo checked out?
From: Daniel Barkalow @ 2005-11-29 2:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511281637480.3177@g5.osdl.org>
On Mon, 28 Nov 2005, Linus Torvalds wrote:
> On Mon, 28 Nov 2005, Daniel Barkalow wrote:
> >
> > We really ought to keep track of what the current checked out tree is,
> > independant of the head that it's supposed to match. Then it would be safe
> > to push to a head that's checked out (it wouldn't update it, but the
> > system would understand what's going on).
>
> Well, that's what branches are all about.
>
> You really have two choices:
> - do it all yourself
> - use git branches
>
> but if you use a special git branch for the checked-out state, then you
> have to realize that nobody can push directly to it.
The idea is to have something which is private, to match the working tree,
which is obviously private (because it doesn't even exist from the point
of view of the database). Of course, you don't want most of the branch
mechanism, with HEAD pointing to a file, because when you commit, you want
to update something else, and when you check out, you want to check out
something else. You want to use a normal git branch, but still have git
keep track of what it thinks should be in your working tree, regardless of
what the branch you're on does, so that checkout doesn't get confused if
somebody's pushed to the branch you're on.
Then, if someone pushes to a branch that's checked out, git doesn't lose
track of what it put in the working tree, so it can handle the "git
checkout" that you do afterwards to update the working tree. Making
everything work okay if multiple "git checkout"s happen at the same time
is future work, and will definitely involve locking.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Fix typo in http-push.c
From: Jan Andres @ 2005-11-29 0:51 UTC (permalink / raw)
To: git
Hi guys,
Please find below the patch for a typo in http-push.c (in the maint
branch), which caused git-http-push to segfault on my Linux i386 box.
Regards,
Jan
diff --git a/http-push.c b/http-push.c
index 76c7886..ad78982 100644
--- a/http-push.c
+++ b/http-push.c
@@ -784,7 +784,7 @@ static void handle_new_lock_ctx(struct x
strtol(ctx->cdata + 7, NULL, 10);
} else if (!strcmp(ctx->name, DAV_ACTIVELOCK_TOKEN)) {
if (!strncmp(ctx->cdata, "opaquelocktoken:", 16)) {
- lock->token = xmalloc(strlen(ctx->cdata - 15));
+ lock->token = xmalloc(strlen(ctx->cdata) - 15);
strcpy(lock->token, ctx->cdata + 16);
}
}
--
Jan Andres <jandres@gmx.net>
^ permalink raw reply related
* Re: keeping remote repo checked out?
From: Linus Torvalds @ 2005-11-29 0:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511281845280.25300@iabervon.org>
On Mon, 28 Nov 2005, Daniel Barkalow wrote:
>
> We really ought to keep track of what the current checked out tree is,
> independant of the head that it's supposed to match. Then it would be safe
> to push to a head that's checked out (it wouldn't update it, but the
> system would understand what's going on).
Well, that's what branches are all about.
You really have two choices:
- do it all yourself
- use git branches
but if you use a special git branch for the checked-out state, then you
have to realize that nobody can push directly to it.
You'd have a trigger that triggers on a push to _another_ branch, and then
the trigger basically does an automatic "git pull" from that branch (and
updates the checked-out state as part of that).
But you _still_ need to do the locking. That's very fundamental. There is
no locking in a "git push", exactly because it can push in parallel, by
design. And you _cannot_ check out a tree in parallel, so you have to do
locking for that.
There's no way you can avoid the locking. You can do shortcuts: for
example, you could avoid any explicit locking by having the "checkout"
just happen once an hour, with an automatic "pull" from the changed
branch. Again, that means that the branch that is checked out can NOT be
one of the branches that people push to.
Linus
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Daniel Barkalow @ 2005-11-29 0:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0511281420390.3263@g5.osdl.org>
On Mon, 28 Nov 2005, Linus Torvalds wrote:
> On Mon, 28 Nov 2005, Petr Baudis wrote:
> >
> > > - should it do 'git-checkout', 'git-reset --hard HEAD', or
> > > 'git-pull . branch_to_push_into'? The former two pretty much
> > > assumes no development happens on the server repository and
> > > git push is used primarily as an installation mechanism.
> >
> > Files should be removed properly, which pretty much excludes the former
> > two, I think.
>
> There are major locking issues with two people pushing at the same time.
>
> The git logic does the right thing for a non-checked-out branch, but it
> can do the right thing exactly _because_ it's not checked out. It can
> create all the new objects whether the actual push succeeds or not, and it
> can do the final switch-over as a single atomic file operation.
>
> The same is most emphatically _not_ true of "git checkout".
>
> In other words, you need to add your very own locking for the shared
> checked-out tree, and you need to (_within_ that lock) separately remember
> what the _previous_ tree was that was checked out, because you can't just
> rely on the previous head as reported by git, because that will have been
> done ourside your "checked out lock".
We really ought to keep track of what the current checked out tree is,
independant of the head that it's supposed to match. Then it would be safe
to push to a head that's checked out (it wouldn't update it, but the
system would understand what's going on).
The rest should be easy from there, just by locking on that file, since
you probably don't care about the race between checking out the head and
updating the head. (You would want to have the case for not getting the
lock loop until it can get the lock, rather than aborting, however, so
that the last version does get checked out even if checkout wins with push
but the hook runs before checkout completes.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: 'git commit' ignoring args?
From: Junio C Hamano @ 2005-11-28 23:44 UTC (permalink / raw)
To: git
In-Reply-To: <438B8C6C.8030407@op5.se>
Andreas Ericsson <ae <at> op5.se> writes:
> The index has been updated to match the file on disk somehow (perhaps
> you did 'git add book.xml'?).
book.xml is known to the index file at this point. "git add book.xml" will
*not* run update-index on that path, so that is not it.
^ permalink raw reply
* Re: 'git commit' ignoring args?
From: Andreas Ericsson @ 2005-11-28 23:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <438B2F40.6070801@pobox.com>
Jeff Garzik wrote:
>
> With the latest git as of this writing, executing
>
> git commit Makefile stylesheet.xsl
>
> results in an attempt to commit the above files, and also another file
> book.xml. book.xml is modified, but I do not wish to check it in at
> this time, so I did not list it as an argument to 'git commit'.
>
The index has been updated to match the file on disk somehow (perhaps
you did 'git add book.xml'?). You can un-mark it with
git reset HEAD
which is equivalent to
git read-tree --reset HEAD
so long as you're operating on HEAD.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Linus Torvalds @ 2005-11-28 22:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20051128212804.GV22159@pasky.or.cz>
On Mon, 28 Nov 2005, Petr Baudis wrote:
>
> > - should it do 'git-checkout', 'git-reset --hard HEAD', or
> > 'git-pull . branch_to_push_into'? The former two pretty much
> > assumes no development happens on the server repository and
> > git push is used primarily as an installation mechanism.
>
> Files should be removed properly, which pretty much excludes the former
> two, I think.
There are major locking issues with two people pushing at the same time.
The git logic does the right thing for a non-checked-out branch, but it
can do the right thing exactly _because_ it's not checked out. It can
create all the new objects whether the actual push succeeds or not, and it
can do the final switch-over as a single atomic file operation.
The same is most emphatically _not_ true of "git checkout".
In other words, you need to add your very own locking for the shared
checked-out tree, and you need to (_within_ that lock) separately remember
what the _previous_ tree was that was checked out, because you can't just
rely on the previous head as reported by git, because that will have been
done ourside your "checked out lock".
And locking really isn't trivial. Especially if you _also_ do this with
multiple clients touching the same checked-out repo over NFS (which I'd
seriously suggest you not do).
There's a really good reason why the git core does _not_ do this. It's
damn complicated.
Linus
^ permalink raw reply
* Re: [PATCH] gitk: UTF-8 support
From: Pavel Roskin @ 2005-11-28 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vr7917hq4.fsf@assigned-by-dhcp.cox.net>
On Sun, 2005-11-27 at 16:12 -0800, Junio C Hamano wrote:
> The following patch on top of your patch has seen only very
> light testing, but it seems to do the right thing for my
> repository with utf-8 commit messages and another with euc-jp
> commit messages. For the latter, I needed to do:
>
> $ git-repo-config i18n.commitencoding euc-jp
Thank you! I'm glad my code was actually useful.
Now we may want to make git recode commit data to the repository
encoding. Lots of iconv/glibc/portability fun on the horizon. At very
least git should protest if both i18n.commitencoding and the locale
encoding are set to different values.
Another issue is support for non-ASCII characters in the filenames.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Junio C Hamano @ 2005-11-28 21:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051128212804.GV22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> Here are the things whoever is doing the hooks/post-update for
>> this particular setup needs to think about.
>>
>> - is it safe to assume that the guy working on the server
>> working tree never switch branches? otherwise, what to do if
>> the working tree has different branch checked out when push
>> called post-update?
>
> I wouldn't do anything. Working copy reflects the HEAD; if you don't
> update HEAD, you needn't touch the working copy.
>
>> - should it allow forced-push that sets HEAD to non descendant
>> of the current HEAD? In a shared repository setup,
>> disallowing forced-push is a good discipline. OTOH, if this
>> is primarily used as an installation mechanism to a remote
>> hosting site, allowing forced-push may be ok.
>
> I would just leave this on the particular head policy.
In case it was not obvious, I was not outlining what I would
want as a git-wide policy. It was meant as an example of things
people need to think about, IOW, what their head policy should
be, if they want to use git in a workflow that magically checks
things out when a push happens.
>> - should it do 'git-checkout', 'git-reset --hard HEAD', or
>> 'git-pull . branch_to_push_into'? The former two pretty much
>> assumes no development happens on the server repository and
>> git push is used primarily as an installation mechanism.
>
> Files should be removed properly, which pretty much excludes the former
> two, I think.
Unless you screw with the branch head under a checked out tree,
git-checkout would remove files properly, and "git-reset --hard"
would do the right thing even when you update the branch head of
a checked out tree. The last one is interesting and might be
useful.
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Petr Baudis @ 2005-11-28 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsltgtvk4.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 28, 2005 at 08:35:23PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Both of us are right and talking about the same thing. You are
> right that as long as hooks/post-update is done correctly the
> one who works on the server should not have to worry. I am
> right that the hooks/post-update for that setup needs to be done
> very carefully ;-).
Aha, then I misunderstood what you wrote before - sorry. Obviously,
you are right. ;-)
> Here are the things whoever is doing the hooks/post-update for
> this particular setup needs to think about.
>
> - is it safe to assume that the guy working on the server
> working tree never switch branches? otherwise, what to do if
> the working tree has different branch checked out when push
> called post-update?
I wouldn't do anything. Working copy reflects the HEAD; if you don't
update HEAD, you needn't touch the working copy.
> - should it allow forced-push that sets HEAD to non descendant
> of the current HEAD? In a shared repository setup,
> disallowing forced-push is a good discipline. OTOH, if this
> is primarily used as an installation mechanism to a remote
> hosting site, allowing forced-push may be ok.
I would just leave this on the particular head policy.
> - should it do 'git-checkout', 'git-reset --hard HEAD', or
> 'git-pull . branch_to_push_into'? The former two pretty much
> assumes no development happens on the server repository and
> git push is used primarily as an installation mechanism.
Files should be removed properly, which pretty much excludes the former
two, I think.
> The latter is to keep a branch, other than "master" that is
> always checked out on the server machine, and have people
> push into a different branch and merge with it automatically
> when a push happens. what would you do when a merge conflict
> happens?
This seems weird and overcomplicated, and it seems to mirror that GIT
does not want to deal with trees containing local modifications - which
is fine, but I don't think you should go over huge hoops in the workflow
to adjust to that. Just verify in the pre-update hook that the tree
contains no local modifications, and disallow the push otherwise. Cogito
can then use own update hooks which will enable it to handle local
changes more gracefully (albeit still not ideally).
> On a tangent, the last point brings up an interesting
> shared-repo usage pattern. When you have a shared central
> repository like CVS, you could arrange things this way:
..snip..
> I am not sure if people would find this useful, though.
It is certainly quite interesting idea. I'm not sure how useful in
practice is it either, though. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: rebase problems
From: Junio C Hamano @ 2005-11-28 21:02 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20051128202428.GA8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Mon, Nov 28, 2005 at 12:19:40PM -0800, Junio C Hamano wrote:
>> The output seems very inconsistent I am not sure why the first
>> message says "Applying HEAD~2", not HEAD~6. What patches do
>> you see in .dotest/ directory, and are they numbered in the
>> right order? HEAD~6 should be numbered 0001 and that should be
>> the first one that was applied.
>
> Ah! It seems .dotest still contained some stuff from a previous
> (expectedly) failed rebase.
>
> Rebase worked after rm -rf'ing .dotest
>
> Maybe rebase should clean up .dotest or at least warn about
> an existing .dotest ?
Thanks, you are right. I was coming to the same conclusion.
There are a few more problems in the current rebase.
- If the branch being rebased is fully in sync with the master
(i.e. there is no patch to apply), it fails with a mysterious
message "fatal: cannot read mbox".
- If the branch being rebased is already a proper descendant of
the master, it still goes ahead and rebases. This is
unnecessary.
I think something like this is necessary.
-- >8 --
[PATCH] rebase: one safety net, one bugfix and one optimization.
When a .dotest from a previously failed rebase or patch
application exists, rebase got confused and tried to apply
mixture of what was already there and what is being rebased.
Check the existence of the directory and barf.
It failed with an mysterious "fatal: cannot read mbox" message
if the branch being rebased is fully in sync with the base.
Also if the branch is a proper descendant of the base, there is
no need to run rebase logic. Prevent these from happening by
checking where the merge-base is.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-rebase.sh | 28 +++++++++++++++++++++++++++-
1 files changed, 27 insertions(+), 1 deletions(-)
applies-to: fe523a4df93cce3e5c5b0266b9d3f1cbea009afa
7f4bd5d831ea838668d1de5f5af022f763230eee
diff --git a/git-rebase.sh b/git-rebase.sh
index 2bc3a12..638ff0d 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -5,9 +5,25 @@
. git-sh-setup
-# The other head is given
+# Make sure we do not have .dotest
+if mkdir .dotest
+then
+ rmdir .dotest
+else
+ echo >&2 '
+It seems that I cannot create a .dotest directory, and I wonder if you
+are in the middle of patch application or another rebase. If that is not
+the case, please rm -fr .dotest and run me again. I am stopping in case
+you still have something valuable there.'
+ exit 1
+fi
+
+# The other head is given. Make sure it is valid.
other=$(git-rev-parse --verify "$1^0") || exit
+# Make sure we have HEAD that is valid.
+head=$(git-rev-parse --verify "HEAD^0") || exit
+
# The tree must be really really clean.
git-update-index --refresh || exit
diff=$(git-diff-index --cached --name-status -r HEAD)
@@ -23,6 +39,16 @@ case "$#" in
git-checkout "$2" || exit
esac
+# If the HEAD is a proper descendant of $other, we do not even need
+# to rebase. Make sure we do not do needless rebase. In such a
+# case, merge-base should be the same as "$other".
+mb=$(git-merge-base "$other" "$head")
+if test "$mb" = "$other"
+then
+ echo >&2 "Current branch `git-symbolic-ref HEAD` is up to date."
+ exit 0
+fi
+
# Rewind the head to "$other"
git-reset --hard "$other"
git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
---
0.99.9.GIT
^ permalink raw reply related
* Re: lost again on syntax change - local repository?
From: Petr Baudis @ 2005-11-28 20:53 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86psok378t.fsf@blue.stonehenge.com>
Dear diary, on Mon, Nov 28, 2005 at 08:25:06PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> localhost:..Git/Play/local.git % cg-push
> WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
> WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
> ssh: \033]2;[zsh] localhost: No address associated with nodename
> fatal: unexpected EOF
Could you please strace it, to see what argument does git-send-pack
take? (Or hijack git-send-pack if you cannot strace on your system.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: rebase problems
From: Sven Verdoolaege @ 2005-11-28 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q5wttib.fsf@assigned-by-dhcp.cox.net>
On Mon, Nov 28, 2005 at 12:19:40PM -0800, Junio C Hamano wrote:
> The output seems very inconsistent I am not sure why the first
> message says "Applying HEAD~2", not HEAD~6. What patches do
> you see in .dotest/ directory, and are they numbered in the
> right order? HEAD~6 should be numbered 0001 and that should be
> the first one that was applied.
Ah! It seems .dotest still contained some stuff from a previous
(expectedly) failed rebase.
Rebase worked after rm -rf'ing .dotest
Maybe rebase should clean up .dotest or at least warn about
an existing .dotest ?
Thanks,
skimo
^ permalink raw reply
* Re: rebase problems
From: Junio C Hamano @ 2005-11-28 20:19 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20051128145814.GW8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> Recently, rebasing has stopped working for me.
> Here is an example:
>
> bash-3.00$ git-show-branch origin HEAD
> ! [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
> ! [HEAD] propagate LinearizationType typo fix.
> --
> + [HEAD] propagate LinearizationType typo fix.
> + [HEAD^] LinearizationType: typo
> + [HEAD~2] espam::DecomposeChannels: actually decompose the channel if valid.
> + [HEAD~3] DecomposeChannels: split channel and check whether result is a pair of fifos.
> + [HEAD~4] Use proper class for LinearizationType.
> + [HEAD~5] espam/../DecomposeChannels: partial implementation.
> + [HEAD~6] espam: add flag for channel decomposition.
> + [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
> ++ [HEAD~7] espam/../IndexVector::toString: include contents of IndexVector.
> bash-3.00$ git rebase origin
>
> Applying 'espam::DecomposeChannels: actually decompose the channel if valid.'
>
> error: pa/espam/operations/transformations/DecomposeChannels.java: does not exist in index
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Trying simple merge.
> Simple merge failed, trying Automatic merge.
> ERROR: pa/espam/operations/transformations/DecomposeChannels.java: Not handling case 09322db769adbc03bfd4f3ac2720c6d1db5a85b1 -> -> 32da8b1de4205c4adb0da50648a0a00d60b67582
> fatal: merge program failed
> Failed to merge in the changes.
> Patch failed at 0007.
> 0001-espam-add-flag-for-channel-decomposition.txt
>
>
> I'm not sure what rebase is doing here, but the only change in origin
> modified a file untouched by the changes in HEAD, so there shouldn't
> be any conflict whatsoever.
> Apparently it's trying to apply the change in HEAD~2 without having
> applied the earlier changes (which and the file named above).
What it should be doing (although I have not seen this kind of
breakage myself, there could be a bug that makes rebase not to
do what it should be doing) is:
- save the original HEAD to .git/ORIG_HEAD
- reset the tree to origin without switching branches
- prepare patches for changes ~6, ~5, ... brings in
- feed that to git-am, which saves the 7 patches in
.dotest/0001 through .dotest/0007 and starts applying them.
As the first thing to do after you see something like this,
please stash away ORIG_HEAD, like this:
$ git branch before-rebase-precious ORIG_HEAD
After this, if you choose not to rebase for whatever reason,
including "rebase is broken X-<", you could do
$ git-reset --hard before-rebase-precious
to come back to the state before trying rebase.
The output seems very inconsistent I am not sure why the first
message says "Applying HEAD~2", not HEAD~6. What patches do
you see in .dotest/ directory, and are they numbered in the
right order? HEAD~6 should be numbered 0001 and that should be
the first one that was applied.
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Junio C Hamano @ 2005-11-28 19:35 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20051128105736.GO22159@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Mon, Nov 28, 2005 at 08:48:26AM CET, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> James Cloos <cloos@jhcloos.com> writes:
>>
>> > Is it possible to arrange that a push does a checkout on the remote
>> > the same way a pull does on the local?
>>
>> Creative use of hooks/post-update would solve that.
>>
>> However, you should be very careful if you sometimes edit on
>> server and sometimes push from other machine to the server on
>> the same branch on the server.
>
> Why? At worst you will get files with conflict markers on the server,
> which isn't that huge problem and just what you have to expect when you
> do this kind of thing.
Both of us are right and talking about the same thing. You are
right that as long as hooks/post-update is done correctly the
one who works on the server should not have to worry. I am
right that the hooks/post-update for that setup needs to be done
very carefully ;-).
Here are the things whoever is doing the hooks/post-update for
this particular setup needs to think about.
- is it safe to assume that the guy working on the server
working tree never switch branches? otherwise, what to do if
the working tree has different branch checked out when push
called post-update?
- should it allow forced-push that sets HEAD to non descendant
of the current HEAD? In a shared repository setup,
disallowing forced-push is a good discipline. OTOH, if this
is primarily used as an installation mechanism to a remote
hosting site, allowing forced-push may be ok.
- should it do 'git-checkout', 'git-reset --hard HEAD', or
'git-pull . branch_to_push_into'? The former two pretty much
assumes no development happens on the server repository and
git push is used primarily as an installation mechanism. The
latter is to keep a branch, other than "master" that is
always checked out on the server machine, and have people
push into a different branch and merge with it automatically
when a push happens. what would you do when a merge conflict
happens?
On a tangent, the last point brings up an interesting
shared-repo usage pattern. When you have a shared central
repository like CVS, you could arrange things this way:
* On the shared repository, prepare one branch per developer
who is pushing into it, plus "master".
* The developer pull from "master" and work in her private
repository. The changes are pushed into her own branch on
the shared repository machine.
* The the shared repository machine tries to merge "master"
into developer branches when the developer branch head is
updated. If it does not trivially resolve, the developer
branch head is left as the last push by the developer
(i.e. not recording the merge). If it does resolve, it is
checked out into playpen area, built and testsuite run, and
if all look well, "master" is updated with the result of the
merge. A notification is sent to the developer to tell which
of the above actions happened.
This does not have to happen in the update hook and you
probably would not want to because it would be a lenthy
operation. The update hook can be used to maintain recent
push log for a cron job that runs the "merge-test-integrate"
procedure to decide which branch is interesting.
I am not sure if people would find this useful, though.
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 19:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051128191546.GT22159@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> Could you try the following, please?
Petr> diff --git a/cg-push b/cg-push
Petr> index 1d59422..323ef26 100755
Petr> --- a/cg-push
Petr> +++ b/cg-push
Petr> @@ -56,13 +56,13 @@ if echo "$uri" | grep -q '#'; then
Petr> uri=$(echo $uri | cut -d '#' -f 1)
Petr> fi
Petr> -if echo "$uri" | grep -q "^http://"; then
Petr> +if [ "${uri#http://}" != "$uri" ]; then
Petr> die "pushing over HTTP not supported yet"
Petr> -elif echo "$uri" | grep -q "^git+ssh://"; then
Petr> +elif [ "${uri#git+ssh://}" != "$uri" ]; then
Petr> send_pack_update "$name" "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" $_git_head$sprembranch "${tags[@]}"
Petr> -elif echo "$uri" | grep -q "^rsync://"; then
Petr> +elif [ "${uri#rsync://}" != "$uri" ]; then
Petr> die "pushing over rsync not supported"
Petr> -elif echo "$uri" | grep -q ":"; then
Petr> +elif [ "${uri#*:}" != "$uri" ]; then
Petr> echo "WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol."
Petr> echo "WARNING: The host:path syntax is evil because it is implicit. Please just use a URI."
Petr> send_pack_update "$name" "$uri" $_git_head$sprembranch "${tags[@]}"
Bizarrely, same behavior. Mark me "puzzled".
localhost:~/Projects/Git/Play % cg-admin-setuprepo remote.git
localhost:~/Projects/Git/Play % mkdir local.git
localhost:~/Projects/Git/Play % cd local.git
localhost:..Git/Play/local.git % cg-init -mempty
defaulting to local storage area
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as ee28097d96063ae660faf325f5bffdbcbc6818f4.
localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
localhost:..Git/Play/local.git % cg-branch-ls
origin /Users/merlyn/Projects/Git/Play/remote.git#master
localhost:..Git/Play/local.git % cg-push
WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
ssh: \033]2;[zsh] localhost: No address associated with nodename
fatal: unexpected EOF
localhost:..Git/Play/local.git % which cg-push
/opt/git/bin/cg-push
localhost:..Git/Play/local.git % grep uri $(which cg-push)
uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
uri=$(echo $uri | cut -d '#' -f 1)
if [ "${uri#http://}" != "$uri" ]; then
elif [ "${uri#git+ssh://}" != "$uri" ]; then
send_pack_update "$name" "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" $_git_head$sprembranch "${tags[@]}"
elif [ "${uri#rsync://}" != "$uri" ]; then
elif [ "${uri#*:}" != "$uri" ]; then
send_pack_update "$name" "$uri" $_git_head$sprembranch "${tags[@]}"
remgit="$uri"; [ -d "$remgit/.git" ] && remgit="$remgit/.git"
send_pack_update "$name" "$uri" $_git_head$sprembranch "${tags[@]}"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Petr Baudis @ 2005-11-28 19:15 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <868xv86dam.fsf@blue.stonehenge.com>
Dear diary, on Mon, Nov 28, 2005 at 03:46:09PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> However, I get this:
>
> localhost:..git/Play/local.git % echo "/Users/merlyn/Projects/git/Play/remote.git" | grep -q ":"
> localhost:..git/Play/local.git % echo $status
> 1
>
> So, perhaps the "bash" on this system is broken for that elif chain?
>
> localhost:..git/Play/local.git % bash --version
> GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
> Copyright (C) 2002 Free Software Foundation, Inc.
>
> Gah. Yet Another Hidden Dependency.
Perplexing. Can't reproduce it with bash-2.05b either.
Could you try the following, please?
diff --git a/cg-push b/cg-push
index 1d59422..323ef26 100755
--- a/cg-push
+++ b/cg-push
@@ -56,13 +56,13 @@ if echo "$uri" | grep -q '#'; then
uri=$(echo $uri | cut -d '#' -f 1)
fi
-if echo "$uri" | grep -q "^http://"; then
+if [ "${uri#http://}" != "$uri" ]; then
die "pushing over HTTP not supported yet"
-elif echo "$uri" | grep -q "^git+ssh://"; then
+elif [ "${uri#git+ssh://}" != "$uri" ]; then
send_pack_update "$name" "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" $_git_head$sprembranch "${tags[@]}"
-elif echo "$uri" | grep -q "^rsync://"; then
+elif [ "${uri#rsync://}" != "$uri" ]; then
die "pushing over rsync not supported"
-elif echo "$uri" | grep -q ":"; then
+elif [ "${uri#*:}" != "$uri" ]; then
echo "WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol."
echo "WARNING: The host:path syntax is evil because it is implicit. Please just use a URI."
send_pack_update "$name" "$uri" $_git_head$sprembranch "${tags[@]}"
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply related
* Re: 'git commit' ignoring args?
From: Junio C Hamano @ 2005-11-28 19:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <438B2F40.6070801@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> With the latest git as of this writing, executing
>
> git commit Makefile stylesheet.xsl
>
> results in an attempt to commit the above files, and also another file
> book.xml. book.xml is modified, but I do not wish to check it in at
> this time, so I did not list it as an argument to 'git commit'.
>
> The only commit in the repository is the initial commit.
>
> #
> # Updated but not checked in:
> # (will commit)
> #
> # modified: Makefile
> # modified: book.xml
> # new file: stylesheet.xsl
> #
> #
> # Untracked files:
> # (use "git add" to add to commit)
> #
> # book.pdf
>
> Expected behavior is that Makefile and stylesheet.xsl would be checked
> in, but not book.xml.
It should work that way, you are right. And it worried me so
much that I tried to reproduce, but I couldn't.
The status output says it will _commit_ book.xml by listing it
in "Updated but not checked in" section, without listing it also
in "Changed but not updated". Which means that when the
git-status was run (that is immediately after 'git-commit'
processed your command line and did git-update-index on Makefile
stylesheet.xsl for you), the index file had book.xml in sync
with your modified version in your working tree.
Could it be that at some point after touching book.xml before
running git commit you did update-index on it?
-- >8 --
Here is what I did to reproduce.
Start afresh.
$ cd /var/tmp/
$ rm -fr jg
$ mkdir jg
$ cd jg
$ git-init-db
defaulting to local storage area
Prepare two files and make initial commit.
$ date >Makefile
$ date >book.xml
$ git add Makefile book.xml
$ git commit -m 'Initial'
Committing initial tree 4a7017a5ec4870d44c340943c66a7f0c1cf4885d
There are two files.
$ git ls-tree HEAD
100644 blob c803676f9cab3249b5b1d225e53b6d14c8545a5e Makefile
100644 blob 6f3b56bbff37d24d9faa78c3e0566cdab4dce8e9 book.xml
Modify two, add one.
$ date >>book.xml
$ date >>Makefile
$ date >stylesheet.xsl
$ git add stylesheet.xsl
See what happened. The index file knows only about addition; we
have not told git about changes we did to book.xml and Makefile
yet.
$ git diff --name-status --cached HEAD
A stylesheet.xsl
The working tree has three changes since the last commit.
$ git diff --name-status HEAD
M Makefile
M book.xml
A stylesheet.xsl
The working tree is different from the index file in two paths.
$ git diff --name-status
M Makefile
M book.xml
Do a partial commit, naming two files.
$ git commit -m 'commit two' Makefile stylesheet.xsl
What's different between the working tree and what we just
committed?
$ git diff --name-status HEAD
M book.xml
We should not have committed changes to book.xml; we haven't.
$ git diff-tree --name-status HEAD
1d3ed9f438aa705fd8433bc23400814468a1a353
M Makefile
A stylesheet.xsl
$ exit
^ permalink raw reply
* Re: use binmode(STDOUT) in git-status
From: Junio C Hamano @ 2005-11-28 18:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511272334w393434e7lad3e3b102e6c3e9e@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> Activision's Perl generates CRLF unless STDOUT is binmoded, which is
> inconsistent with other output of git-status.
I do not think this is a kind of patch that I should accept to
apply to the generic part of the codepath, even if on sane
platforms binmode() could be a no-op.
You should not have to say binmode() when you are emitting plain
text (otherwise you have to say that everywhere which is
madness). I presume the Cygwin version uses Perl from Cygwin
and would not have this problem?
If that is the case, maybe this patch should be maintained out
of tree by the maintainer of Windows port of git that does _not_
use Cygwin but ActiveState.
^ permalink raw reply
* Re: use binmode(STDOUT) in git-status
From: Johannes Schindelin @ 2005-11-28 16:56 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <438B2B90.9010500@zytor.com>
Hi,
On Mon, 28 Nov 2005, H. Peter Anvin wrote:
> if you're running Cygwin, wouldn't Cygwin's Perl make a lot more sense?
I thought so, too, but I guess there's a reason that Activision's perl was
used.
Hth,
Dscho
^ permalink raw reply
* [Question] Fetching a new branch from remote
From: Carl Baldwin @ 2005-11-28 16:33 UTC (permalink / raw)
To: git
Greetings,
I have a short question about git fetch. Say there is a new branch,
call it 'new-branch' in a remote repository. I am interested in this
branch and want to fetch it to 'new-branch' in my local to track its
progress.
I would expect this to do it:
% git fetch -f <url> new-branch
But, it doesn't.
Actually, I just noticed that this accomplishes the desired result...
% git fetch <url> new-branch:new-branch
I also just noticed that the man pages only says that '-f' works on
tags. Should it work on branches? Either way, it wasn't clear to me
how to fetch a new branch from a remote and store it under the same name
locally. In my opinion, git fetch -f should do this if given a
branchname from the remote.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Johannes Schindelin @ 2005-11-28 16:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051128135915.GR22159@pasky.or.cz>
Hi,
On Mon, 28 Nov 2005, Petr Baudis wrote:
> As I said, I don't care much if this moves to the git configuration
> file, but please don't merge it with the remotes.
As you have made quite clear, it is for *you* to decide if you want to
move .git/branches/ anywhere. I wrote the automatic conversion only to
demonstrate how I thought how a migration *could* be done painlessly, if
the information goes into .git/config.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Johannes Schindelin @ 2005-11-28 16:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyph1ebq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 27 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I only realized that we -- in the good tradition of UNIX -- have many
> > different formats for different configurations: Some configurations are in
> > .gitignore, some are in .git/branches/, some in .git/remotes/, some in
> > .git/config, and even some in environment variables!
>
> Can you live with something like this?
>
> - we will add new ones to config, now we have it;
>
> - we will not deprecate existing ones outside of config for some time;
>
> - we will not duplicate/move existing ones into config at least
> for now to keep our work less complicated;
>
> - we would revisit deprecating things outside config file
> sometime later after 1.0 stabilizes, and that's when we will
> talk about moving these things into config.
I can very well live with this!
As a first step, we could support getting the remote information from
.git/config after testing .git/branches/ and .git/remotes/?
Ciao,
Dscho
^ permalink raw reply
* 'git commit' ignoring args?
From: Jeff Garzik @ 2005-11-28 16:24 UTC (permalink / raw)
To: Git Mailing List
With the latest git as of this writing, executing
git commit Makefile stylesheet.xsl
results in an attempt to commit the above files, and also another file
book.xml. book.xml is modified, but I do not wish to check it in at
this time, so I did not list it as an argument to 'git commit'.
The only commit in the repository is the initial commit.
#
# Updated but not checked in:
# (will commit)
#
# modified: Makefile
# modified: book.xml
# new file: stylesheet.xsl
#
#
# Untracked files:
# (use "git add" to add to commit)
#
# book.pdf
Expected behavior is that Makefile and stylesheet.xsl would be checked
in, but not book.xml.
Jeff
^ permalink raw reply
* Re: use binmode(STDOUT) in git-status
From: H. Peter Anvin @ 2005-11-28 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0511281700100.11362@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> Of course, here is the problem: git on Windows runs only using cygwin. You
> can specify the line ending behaviour of cygwin (I think it is an env
> variable). Activision Perl, being independent of cygwin, does not care
> about that setting.
>
> So, to be accurate, you'd have to check what *cygwin* expects, and
> depending on that execute binmode(STDOUT) or not.
>
Makes sense, I guess... except if you're running Cygwin, wouldn't
Cygwin's Perl make a lot more sense?
-hpa
^ 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