Martin Langhoff <[EMAIL PROTECTED]> writes:
> Hmmm. That repo is in sync, but there are no guarantees that they will
> travel together to a different repo. In fact, the push/pull
> infrastructure wants to push/pull one head at a time.
>
> And if they are not in sync, I have no way of knowing. Hmpf
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> > Hmmm. That repo is in sync, but there are no guarantees that they will
> > travel together to a different repo. In fact, the push/pull
> > infrastructure wants to push/pull one head at a time.
>
> Wrong as of last week ;-), and definitely w
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I don't think this buys you anything, because then the tag needs to be
> accessible from something, which is the same problem you were trying to
> solve for the commit.
Actually not. My suggestion was a qualified one: "If all you
need is a textual in
Linus Torvalds <[EMAIL PROTECTED]> writes:
> That kind of extension shouldn't be too hard, and might make tags much
> more generally usable (ie you could say "I sign these official
> releases" or something).
Well, I admit that once I advocated changing "tag" to "bag", but
one problem is how yo
On Fri, 26 Aug 2005, Daniel Barkalow wrote:
>
> I don't think this buys you anything, because then the tag needs to be
> accessible from something, which is the same problem you were trying to
> solve for the commit.
Yes.
We had an earlier discussion somewhat along these lines, where a
"coll
On Wed, 24 Aug 2005, Daniel Barkalow wrote:
> Of course, this is going to take a bit of work, because read-tree
> currently puts all of its arguments into the cache and then works on
> merging, and taking multiple ancestors requires putting them somewhere
> else, because they won't fit in the cach
Various updates and cleanups for my howto on using branches in GIT
as a Linux subsystem maintainer. Three categories of changes:
1) Updates for new features in GIT 0.99.5
2) Changes to use "git fetch" rather than "git pull" to update local linus
branch.
3) Cleanups suggested by Len Brown
Signed-
On Thu, 25 Aug 2005, Junio C Hamano wrote:
> Now, among the existing object types, there are only two kinds
> of objects you can use for this. If the only thing you need to
> record is some textual information with one pointer to git
> branch head, then you can use tag that points at the git head
Martin Langhoff <[EMAIL PROTECTED]> writes:
>> In other words, if you just have a "last commit" pointer in your
>> meta-data, then git is _by_definition_ in sync. There's never anything to
>> get out of sync, because objects aren't going to change.
>
> Hmmm. That repo is in sync, but there are no
On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > OTOH, storing the metadata in a branch will allow us to run the import
> > in alternating repositories. But as Junio points out, unless I can
> > guarantee that the metadata and the tree are in sync, I cannot
> > trivially resume the import
On Thu, 25 Aug 2005, Junio C Hamano wrote:
> One thing that makes me reluctant to recommend this "merging
> unrelated projects" business is that I suspect that it makes
> things _much_ harder for the upstream project that is being
> merged, and should not be done without prior arrangement; Linus
>
On Fri, 26 Aug 2005, Martin Langhoff wrote:
>
> OTOH, storing the metadata in a branch will allow us to run the import
> in alternating repositories. But as Junio points out, unless I can
> guarantee that the metadata and the tree are in sync, I cannot
> trivially resume the import cycle from a
Yes it was irritating.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Linus Torvalds <[EMAIL PROTECTED]> writes:
> [ Junio, the fact that you can't script the initial commit with "git
> commit" is _really_ irritating. ]
git-commit-script | 86 ---
On 8/26/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> If I am not mistaken, we have another foreign SCM import
> interface that can repeatedly slurp from the same foreign SCM to
> get updates. Doesn't cvsimport have the same issue?
Yes and no.
cvsimport uses cvsps which uses in ~/.cvsps as
Linus,
I like the solution you are suggesting, but I suspect it will create
more problems that it will solve, and while the coolness factor is
drawing me in we ain't gonna need it, as the xp people say.
More below...
On 8/26/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Git won't care, so
You can define WITH_SEND_EMAIL to include the send-email command as
part of the installation. Since Debian, unlike RPM/Fedora, has the
two necessary Perl modules available as part of the mainline
distribution, there is no reason for us to shy away from shipping
send-email.
Signed-off-by: Junio C
"Luck, Tony" <[EMAIL PROTECTED]> writes:
> What I want is to get the latest from kernel.org...linus...master
> and update my .refs/heads/linus with the new SHA1.
>
> I'd like to be able to do that without touching what is in my
> index, and without changing the state of any checked out files.
>
>
Earlier, I said:
Subject: Re: cache status after git pull
Date: Thu, 25 Aug 2005 13:26:07 -0700
Message-ID: <[EMAIL PROTECTED]>
> 1) Updated my "linus" branch:
>
> $ git checkout linus && git pull linus
The second command, "git pull linus", would internally run "git
On Thu, 2005-08-25 at 15:26 -0700, Junio C Hamano wrote:
> empty=`GIT_INDEX_FILE=.no-such-file git-write-tree`
> git-read-tree -m -u $empty $head $foreign ||
o. Tricky.
Thanks for the script. That's a bad, bad hack. :-)
> One thing that makes me reluctant to recommend this "m
Darrin Thompson <[EMAIL PROTECTED]> writes:
> I have a weird situation I want to support. I want to be able to merge a
> foreign-tree repeatedly.
>
> What makes the foreign tree foreign is that it may not yet share any
> history with this branch.
I believe that's exactly what Linus did when he me
On Thu, Aug 25, 2005 at 04:09:29PM -0500, Kirby C. Bohling wrote:
> I guess I can see that. I just see it as much easier to manage
> multiple undo-redo states manually. I mean, I wouldn't make anyone
> use git directly if the difference between the two commands bothers
> them. git seems too low
That didn't come out clearly. Restating:
On Thu, 2005-08-25 at 16:10 -0500, Darrin Thompson wrote:
> Could git-read-tree -m 3-args be made smart enough to treat a 0 as arg 1
> as an implicit empty tree?
>
Could git-read-tree -m treat an argument of "0" as an implicit empty
tree? It mainly seems
On Thu, Aug 25, 2005 at 03:49:30PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> > "Kirby C. Bohling" <[EMAIL PROTECTED]> writes:
> Just out of curiosity, why isn't the SHA1 of 'A' part of the
> diff or patch format? I mean it can't be that
On Thu, Aug 25, 2005 at 02:37:33PM -0600, Carl Baldwin wrote:
> On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
> > On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> >
> > > Another example is if I'm working on a commit and suddenly get a
> > > brilliant idea for so
On Thu, Aug 25, 2005 at 01:19:05PM -0700, Junio C Hamano wrote:
> "Kirby C. Bohling" <[EMAIL PROTECTED]> writes:
>
> > I guess my final question is what does undo/redo have over saving
> > stuff away in a patch assuming that the patch captures all of the
> > SCM meta-data (the add/move/remove file
>To set up "linus" short-hand to be updated with "master" branch
>head from Linus, you would do one of the following:
>
> * Using new style shorthand
>
>$ cat >$GIT_DIR/remotes/linus \
>URL: http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
>Pull: master:linus
>
On Thu, Aug 25, 2005 at 02:59:18PM -0500, Kirby C. Bohling wrote:
> On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
>
> > Another example is if I'm working on a commit and suddenly get a
> > brilliant idea for some easy modification that I want to make and commit
> > by itself before
[EMAIL PROTECTED] writes:
> Aha ... is this the problem that caught me out last week (when
> I ended up with 10 extra files attached to one of my commits)?
Plausible.
> 1) Updated my "linus" branch:
>
> $ git checkout linus && git pull linus
I would assume that just after "git checkout linus"
"Kirby C. Bohling" <[EMAIL PROTECTED]> writes:
> I guess my final question is what does undo/redo have over saving
> stuff away in a patch assuming that the patch captures all of the
> SCM meta-data (the add/move/remove file type commands). If git
> doesn't capture all the meta-data in a patch, i
On Thu, Aug 25, 2005 at 10:32:01AM -0600, Carl Baldwin wrote:
> Another example is if I'm working on a commit and suddenly get a
> brilliant idea for some easy modification that I want to make and commit
> by itself before making this commit. I can do this easily with
>
> % git undo
>
On Thu, 25 Aug 2005, Jan Veldeman wrote:
> Daniel Barkalow wrote:
>
> > I'm not sure how applicable to this situation stgit really is; I see stgit
> > as optimized for the case of a patch set which is basically done, where
> > you want to keep it applicable to the mainline as the mainline advances
On Wed, 2005-08-24 at 19:38 -0700, Junio C Hamano wrote:
> * Update tutorial to cover shared repository style a bit more,
> maybe with a toy project that involves two or three
> repositories.
>
Shameless plug: Feel free to use/modify/steal my writeup:
http://willowbend.cx/archives/2005/08/24
Add -c parameter to cg-commit to set commit data based on prior commit.
This will then commit any changes using the author and message from the commit
specified. The actual logic for parsing the old commit values was taken from
git-commit-script.
git-commit-script supports this option via -C, wh
[ Junio, the fact that you can't script the initial commit with "git
commit" is _really_ irritating. ]
On Thu, 25 Aug 2005, Martin Langhoff wrote:
>
> Is there a convention of where/how it is safe to store additional
> (non-git) data in $GIT_DIR?
There's no convention, but I have a suggestio
Carl Baldwin <[EMAIL PROTECTED]> writes:
> For this, I may also use branching, as suggested. I meant for undo/redo
> to be a lighter weight alternative to allow for a faster context switch.
I have been missing the undo command since I started to use git, so
I'll share a user's perspective.
I w
On Wed, Aug 24, 2005 at 10:06:45PM -0700, Junio C Hamano wrote:
> > So, I've tried cloning, pulling to|from, pushing to|from and resolving
> > merges in a repository with undo information stored under
> > .git/refs/undo. None of these operations seem to notice the existence
> > of this directory.
>* When the branch head pointed by $GIT_DIR/HEAD changes while
> the index file and working tree are looking the other way
> (e.g. somebody pushed into your repository, or you ran "git
> fetch" to update the ref your working tree is on), "git
> checkout" without -f gets confused. Figure out a good
Describe a DAG and octopus, and change wording of tree object.
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
Documentation/glossary.txt | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
e077919262930f6ce494c963d23317eb2aaf0dd3
diff --git a/Documentation/glos
Hey, that's a nice one. Now I can easily go through my code without using the
web interface. It would be nice if you could mark the lines that have changed
in bold or whatever. It would also be nice, to add the current uncommitted
working version as "newest revision".
Stagger (Please CC me, as
Daniel Barkalow wrote:
[...]
> > The parents which should be visible to the outside, will always be versions
> > of my development tree, which I have previously pushed out. My way of
> > working would become:
> > * make changes, all over the place, using stgit
> > * still make changes (none of the
Hi, Daniel Barkalow wrote:
> My proposal is actually to detect when a merge is ambiguous. In order to
> determine that, however, you have to evaluate multiple potential outcomes
> and see if they are actually different. I'm working on an efficient way to
> do that.
Good.
There's also a related p
41 matches
Mail list logo
