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
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
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
* 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 way to
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 was
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,
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:
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, it would
[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 before
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:
snip...
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
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:
snip...
Another example is if I'm working on a commit and suddenly get a
brilliant idea for some
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 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 a
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 merged
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
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
fetch
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.
If that is
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
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
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 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 new
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 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 cycle
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 guarantees
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
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 cache.
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 n official
releases or something).
Well, I admit that once I advocated changing tag to bag, but
one problem is how you would
27 matches
Mail list logo
