Hi,
On Mon, 22 Aug 2005, Jeff Carr wrote:
> patch:
> git-diff-files -p
"git diff"
> push:
> git-send-pack `cat .git/branches/origin`
"git push origin" (or maybe "git push HEAD:origin")
> pull:
> git-pull-script `cat .git/branches/origin`
> git-read-tree -m HEAD
>
Is there any way to merge patches "selectively"?
I have found that if I do
cg-pull
cg-log -r master:origin
I can review the commits that will be merged if I do cg-update.
Say I do cg-update, it brings a lot of commits and there is a messy
conflict. I immediately can narrow down on whi
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> I think that both, default and non-default persistant
> mappings, are only a handy convenience issue for less
> typing. If GIT core is not doing this, some (most?) porcelains
> will invent their own way for storing these mappings.
Suppose I have so
Jeff Carr <[EMAIL PROTECTED]> writes:
> So my small "feature" request reduces to adding
> something like this to git-pull-script. Thanks, Jeff
Somebody else earlier asked for fetch and pull to default to
"origin" URL, and the necessary change is already in the
proposed updates branch.
-
To unsub
Jeff Carr <[EMAIL PROTECTED]> writes:
> Something simple like the perl script at the bottom would be useful for
> showing files that haven't been added via git-update-cache --add already.
If I am not mistaken, you just reinvented:
$ git ls-files --others
in a very expensive way. Notice you
Something simple like the perl script at the bottom would be useful for
showing files that haven't been added via git-update-cache --add already.
I've also found it useful to start adding things to the Makefile's of
the projects I'm putting in git repositories. I think it would be useful
to come u
On 08/22/2005 01:18 PM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Aug 2005, Jeff Carr wrote:
>
>
>>It would be nice if the URL could be stored somewhere in .git/ This
>>makes it a lot easier to update repositories because you don't always
>>have to go and track down where you got it in the
I have been feeling that the current behaviour of "git reset" is
not quite optimal, but so far could not express exactly what I
felt was wrong with it. This patch clarifies it.
There are at least two situations you may want to "reset" your
working tree.
1. You made a mess in your working tree.
When "git-diff-script A..B" notation was introduced, it ended up breaking
the traditional two revisions notation.
[jc: there are other issues with the current "git diff" I would like to
address, but they would be left to later rounds. For example, -M and -p flags
should not be hardcoded default
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> I think that both, default and non-default persistant
> mappings, are only a handy convenience issue for less
> typing. If GIT core is not doing this, some (most?) porcelains
> will invent their own way for storing these mappings (like
> Cogito is d
Dirk Behme <[EMAIL PROTECTED]> writes:
>>>Seems to me that this breaks http update
Let's clarify one thing first. Did you mean "git rebuilt from
the sources obtained from that seemingly-odd commit, http update
does not work anymore", or did you mean "starting from the state
my repository happene
Jan Veldeman <[EMAIL PROTECTED]> writes:
> ... So as you said: we indeed need a git designer to clear this up
> for us.
I understand I am counted as one of the "git designers"; I have
been aware of this thread but I have to admit that I am way
behind and have not caught up with the issues. I'll
This generalizes the git "glob" string to be a lot more like the
git-diff-* pathspecs (but there are still differences: the diff family
doesn't do any globbing, and because the diff family always generates the
full native pathname, it doesn't have the issue with "..").
It does three things:
Dirk Behme <[EMAIL PROTECTED]> writes:
> Seems to me that this breaks http update
>
> cg-update http://www.kernel.org/pub/scm/git/git.git
>
> error: Tried
> http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
> Cannot obtain needed blob 6ff87c4664981e439762
Junio C Hamano wrote:
Dirk Behme <[EMAIL PROTECTED]> writes:
Seems to me that this breaks http update
cg-update http://www.kernel.org/pub/scm/git/git.git
error: Tried
http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
Cannot obtain needed blob 6ff8
Junio C Hamano wrote:
A couple of people noticed that the latest commit in the
"master" branch seems, eh, odd.
Seems to me that this breaks http update
cg-update http://www.kernel.org/pub/scm/git/git.git
error: Tried
http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e439762579
Sam Ravnborg <[EMAIL PROTECTED]> writes:
>> So you would naturally be tempted to do this:
>>
>> ... Re-edit, compile, and test. This time it is perfect.
>> $ git commit -a -C ORIG_HEAD
>>
>> Well, not really. You can lose any file newly created in
>> ORIG_HEAD this way. Instead, you n
On Sun, 21 Aug 2005, Jan Veldeman wrote:
> Catalin Marinas wrote:
>
> > > So for example, you only tag (freeze) the history when exporting the
> > > patches. When an error is being reported on that version, it's easy to
> > > view
> > > it and also view the progress that was already been made on
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: master:master pu:pu foo:bar
> >
> > Isn't this mi
Hi,
On Mon, 22 Aug 2005, Jeff Carr wrote:
> It would be nice if the URL could be stored somewhere in .git/ This
> makes it a lot easier to update repositories because you don't always
> have to go and track down where you got it in the first place.
This is why your original target (when you clon
It would be nice if the URL could be stored somewhere in .git/ This
makes it a lot easier to update repositories because you don't always
have to go and track down where you got it in the first place. Something
like this perhaps:
~$ cat .git/location
rsync://rsync.kernel.org/pub/scm/linux/kernel/g
21 matches
Mail list logo
