On Saturday 20 August 2005 20:54, Junio C Hamano wrote:
> Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> >>$ cat $GIT_DIR/remotes/www
> >>URL: http://www.kernel.org/pub/scm/git/git.git/
> >>Pull: master:ko-master pu:ko-pu
> >>Push: m
On Thursday 18 August 2005 09:24, Junio C Hamano wrote:
> $ cat $GIT_DIR/remotes/www
> URL: http://www.kernel.org/pub/scm/git/git.git/
> Pull: master:ko-master pu:ko-pu
> Push: master:master pu:pu foo:bar
Isn't this mixing two kinds of information:
1) Some default/persisten
On Saturday 13 August 2005 11:08, Junio C Hamano wrote:
> Also add --verify to make sure the lines you introduced are
> clean, which is more useful in commit but not very much in
> format-patch as it was originally implemented, because finding
> botches at format-patch time is too late.
I think th
On Saturday 13 August 2005 21:27, Junio C Hamano wrote:
> Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> > Or is there already an easy way to detect the fast-forward situation in
> > the script?
>
> Since you are given old and new, presumably you can do
> merge-b
On Sunday 31 July 2005 21:17, Josef Weidendorfer wrote:
> Added hook in git-receive-pack
Regarding the update hook:
In this script, it would be nice to be able to distinguish rebasing/forced
setting of a head from a regular fast forwarding. In the first case, I do not
want to potentially sen
On Monday 08 August 2005 12:36, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > Your example defaults to the master head.
>
> My point being that I still can say
>
> git pull x some_non_default_head
>
> with a fi
On Monday 08 August 2005 11:55, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > IMHO, $GIT_DIR/branches/ is really confusing.
> > Hmmm... in $GIT_DIR/branches/ there are named references to remote
> > (named) references.
>
>
On Monday 08 August 2005 11:10, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Aug 2005, Junio C Hamano wrote:
> > I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> > Maybe we should rename it to $GIT_DIR/remote/ directory?
>
> I'd prefer $GIT_DIR/remotes/.
IMHO, $GIT_DIR/branches/
On Wednesday 03 August 2005 20:07, Junio C Hamano wrote:
> Josef, could you give it a try please?
Perfect. Thanks.
Josef
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
On Wednesday 03 August 2005 19:08, you wrote:
> Yes it is. To reproduce:
You do not need 2 clones.
It is enough to have one clone with a branch, and you make a commit in the
original repository.
Afterwards, pushing a new commit from the clone gives the error.
After pulling the missing commit fro
On Wednesday 03 August 2005 19:37, you wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > I started out to make the "-f" flag to send-file work around it, but I
> > never finished that, partly because it really ends up being the same
> > thing as "git-fetch-pack" in reverse, which was against
On Wednesday 03 August 2005 18:50, you wrote:
> Hi,
>
> On Wed, 3 Aug 2005, Linus Torvalds wrote:
> > Are you sure you have a good git version on master? I've never seen
> > anything like that, and I push all the time..
>
> Call him Zaphod: he has two heads (master and pu). You don't. As I said in
On Sunday 31 July 2005 22:15, Junio C Hamano wrote:
> Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> > +It is assured that sha1-old is an ancestor of sha1-new (otherwise,
> > +the update would have not been allowed). refname is relative to
> > +$GIT_DIR; e.g. for th
Added hook in git-receive-pack
After successful update of a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha2
is called if present. This allows e.g sending of a mail
with pushed commits on the remote repository.
Documentation update with example hook included.
Signed-off-by: Josef
Hi,
On Friday 29 July 2005 09:48, you wrote:
> Petr Baudis <[EMAIL PROTECTED]> writes:
> > So, what do you mean by "clone" here? And what command should I use for
> > pushing then?
...
> Now, A may happen to be on my home machine and B may happen be
> on my notebook, meaning the owner of A and B a
On Thursday 28 July 2005 17:56, Johannes Schindelin wrote:
> localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
> anyway :-)
GIT/Cogito usage is not about linux kernel only.
I actually try to work with a scenario for a project with a few developers,
where each one should h
Hi,
if I clone a remote head other than master via Cogito with
cg-clone host:path#remoteHead,
work on this branch, and try to push back my changes with
cg-push,
I get the error
"pushing to a different head not supported yet".
As far as I can see, there is no support i
17 matches
Mail list logo
