On Mon, Mar 18, 2013 at 02:30:23PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
I don't think you can avoid the 3-step problem and retain the safety in
the general case. Forgetting implementation details for a minute, you
have either a 1-step system:
1. Fetch and start using
On Tue, Mar 12, 2013 at 01:01:08AM +0530, Ramkumar Ramachandra wrote:
But it was pointed out that you could also just do:
$ git config include.ref upstream-config
$ git show origin/config ;# make sure it looks reasonable
$ git show origin/config .git/upstream-config
and so
Jeff King wrote:
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify
Ramkumar Ramachandra artag...@gmail.com writes:
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.
Note that you need to carefully pick only
Thomas Rast wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.
Note that you need to
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone. There
are
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
There are also other things in .git/config that would be nice to
share, like whether to do a --word-diff (why isn't it a configuration
variable yet?)
Because that would break
On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone. There
are
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
Jonathan Nieder jrnie...@gmail.com writes:
Wait, why did the remote rewind?
Oh, I am very well aware of that glitch.
git push has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.
It shouldn't have been made to do so unconditionally; instead it
On Thu, Feb 07, 2013 at 10:45:07PM -0800, Junio C Hamano wrote:
To support a triangular arrangement well, there may need some
thinking on what $branch@{upstream} means. The original intent of
the upstream mode specified for push.default is push the result
back to what you based your work on,
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com writes:
Wait, why did the remote rewind?
Oh, I am very well aware of that glitch.
git push has this hack to pretend as if the pusher immediately
turned around and fetched from the remote.
It
Michael J Gruber g...@drmicha.warpmail.net writes:
As for the triangle remote, I really think we should clean up the
situation regarding push, pushurlinsteadof and the various different and
inconclusive output formats of git remote (with or without -v, with
or without a remote name) first,
Michael J Gruber g...@drmicha.warpmail.net writes:
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com writes:
Wait, why did the remote rewind?
Oh, I am very well aware of that glitch.
git push has this hack to pretend as if the pusher immediately
Junio C Hamano wrote:
Jeff King p...@peff.net writes:
We have the problem now that new users do not necessarily understand the
matching strategy, or why it is useful, and get confused. When we move
to simple, we may be switching to a world where the early part of the
learning curve is more
Junio C Hamano wrote:
[remote origin]
url = ... where Ram fetches and pulls from ...
pushurl = ... where Ram pushes to ...
fetch = refs/heads/*:refs/remotes/*
updateTrackOnPush = no
Then git fetch (or git pull) will
Michael J Gruber wrote:
Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
Jonathan Nieder jrnie...@gmail.com writes:
Wait, why did the remote rewind?
Oh, I am very well aware of that glitch.
git push has this hack to pretend as if the pusher immediately
turned around and fetched from
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
And yes, a regular `git push origin refs/for/master` is just retarded.
The usual incantation is git push gerrit HEAD:refs/for/master. Is
the code review creation push that uses a different branchname from
the branch the integrator pulls
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
[remote origin]
url = ... where Ram fetches and pulls from ...
pushurl = ... where Ram pushes to ...
fetch = refs/heads/*:refs/remotes/*
On 02/07/2013 05:14 PM, Ramkumar Ramachandra wrote:
This has been annoying me for a really long time, but I never really
got around to scratching this particular itch. I have a very common
scenario where I fork a project on GitHub. I have two configured
remotes: origin which points to
Ramkumar Ramachandra wrote:
Ramkumar Ramachandra wrote:
And yes, a regular `git push origin refs/for/master` is just retarded.
Actually a git config remote.origin.push refs/heads/*:refs/for/* makes
more sense here.
Sorry about all that confusion. The first line should be `git push
origin
Hi Ram,
Ramkumar Ramachandra wrote:
And yes, a regular `git push origin refs/for/master` is just retarded.
The usual incantation is git push gerrit HEAD:refs/for/master. Is
the code review creation push that uses a different branchname from
the branch the integrator pulls what seems backward,
Jonathan Nieder jrnie...@gmail.com writes:
The usual incantation is git push gerrit HEAD:refs/for/master. Is
the code review creation push that uses a different branchname from
the branch the integrator pulls what seems backward, or is it the need
to specify a refname at all on the command
to
configure each branch independently as you create it. I'm imagining
lookup rules something like:
1. If we are on branch $b, check branch.$b.pushRemote.
2. If not set, check remote.pushDefault.
3. If not set, check branch.$b.remote.
4. If not set, check remote.default (there was a proposal
Jeff King p...@peff.net writes:
On Thu, Feb 07, 2013 at 09:44:59PM +0530, Ramkumar Ramachandra wrote:
This has been annoying me for a really long time, but I never really
got around to scratching this particular itch. I have a very common
scenario where I fork a project on GitHub. I have
On Thu, Feb 07, 2013 at 10:08:48PM -0800, Junio C Hamano wrote:
How best to express the triangle is somewhat tricky, but I think it
is sensible to say you have origin that points to your upstream
(i.e. me), and peff that points to your publishing point, in other
words, make it explicit that
Junio C Hamano gits...@pobox.com writes:
I think the triangle
arrangement where you want to have this is where I fetch from and
integrate with, and that is where I publish is more common among
the Git users these days.
Another thing to know about is that the recent move to change the
Junio C Hamano wrote:
I'd actually see this as Gerrit being weird.
If it wants to quarantine a commit destined to the master branch,
couldn't it just let people push to master and then internally
update for/master instead?
It is because pushing doesn't update refs/heads/master. Instead, it
On 01/04/2013 10:40 PM, Junio C Hamano wrote:
Micheil Smith mich...@brandedcode.com writes:
This patch implements a git stash rename using a new
git reflog update command that updates the message associated
with a reflog entry.
...
I note that this proposal is now two years old. A work
stash rename using a new
git reflog update command that updates the message associated
with a reflog entry.
---
[--snip--]
Hi,
I note that this proposal is now two years old. A work in progress patch was
requested, however, after one was given this thread ended. I'm also finding
a need
Micheil Smith mich...@brandedcode.com writes:
This patch implements a git stash rename using a new
git reflog update command that updates the message associated
with a reflog entry.
...
I note that this proposal is now two years old. A work in progress patch was
requested, however, after
Martin von Zweigbergk martinv...@gmail.com writes:
On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote:
I am guilty of introducing git reset --soft HEAD^ before I invented
commit --amend during v1.3.0 timeframe to solve the issue soft reset
originally wanted to.
I do
On Mon, Dec 17, 2012 at 10:34:07PM -0800, Martin von Zweigbergk wrote:
On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote:
I am guilty of introducing git reset --soft HEAD^ before I invented
commit --amend during v1.3.0 timeframe to solve the issue soft reset
On Wed, Nov 23, 2011 at 12:49 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Philippe Vaucher philippe.vauc...@gmail.com writes:
Optional: a new mode would be introduced for consistency:
--worktree (or maybe --tree): only updates the worktree but not the index
That would be an alias
On Wed, Nov 23, 2011 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote:
I am guilty of introducing git reset --soft HEAD^ before I invented
commit --amend during v1.3.0 timeframe to solve the issue soft reset
originally wanted to.
I do use commit --amend a lot, but I still appreciate having
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote:
I said that git reset --keep started out as an ugly workaround for
the lack of git checkout -B $current_branch. Now we have it, so
we can afford to make reset --keep less prominently advertised in
our tool set. As I already said back then,
Phil Hord phil.h...@gmail.com writes:
I flagged this for followup in my MUA, but I failed to follow-up after
the holidays. I apologize for that, and I really regret it because I
liked where this was going.
I really regret to see you remembered it, actually.
1) Newbie user clones/pulls a
Junio C Hamano gits...@pobox.com writes:
Phil Hord phil.h...@gmail.com writes:
I flagged this for followup in my MUA, but I failed to follow-up after
the holidays. I apologize for that, and I really regret it because I
liked where this was going.
I really regret to see you remembered it,
Thanks for the tip. It should give me a good starting point for what
I'm about to do, since notes seem to be able to add comments for
objects without changing the commit tree (which was one of the things
I was aiming for and quite frankly, one of the parts that worried me
on the implementation
On 23 August 2012 08:10, Catalin Pol catalin@gmail.com wrote:
Hi everyone,
This is my first email to this mailing list, so this may be somehow
too straight forward... the idea is that I was thinking to develop a
new feature in Git (although I'm kind of new to git myself).
I wrote a small
On Mon, Jul 23, 2012 at 2:17 PM, John Bartholomew
jpa.bartholo...@gmail.com wrote:
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own script to do this. It produces output like this:
$ git lsb
commodity-market-lua
John Bartholomew jpa.bartholo...@gmail.com writes:
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream.
That is already present: just run git branch -vv.
--
Thomas Rast
I noticed people on this mailing list start talking about using blob deltas
for compression, and the basic issue that the resulting files are too small
for efficient filesystem storage. I thought about this a little and decided
I should send out my ideas for discussion.
In my proposal
On 4/22/05, Michel Lespinasse [EMAIL PROTECTED] wrote:
I noticed people on this mailing list start talking about using blob deltas
for compression, and the basic issue that the resulting files are too small
for efficient filesystem storage. I thought about this a little and decided
I should
In this message, a method to simplify and at the same time make more
powerful the git abstraction is presented.
I believe that the enhancements I propose make git adhere even more to
its spirit and make it more intuitive.
The proposal makes it much easier to build an SCM over git, obtaining
301 - 346 of 346 matches
Mail list logo
