* Re: Three-way merge with the index as one way
From: Petr Baudis @ 2005-11-03 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zack Brown, git
In-Reply-To: <7vy846ma65.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Nov 03, 2005 at 09:02:10AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> git-am 3-way fallback logic constructs a sparse
> temporary tree and uses it for running regular 3-way, and you
> may be able to do something similar.
I'm confused now - if the tree is sparse, how does git-read-tree -m know
that the missing files from the other tree are not deletes?
> Right now git-am takes an
> e-mail patch and when it runs all the way it creates a commit,
> but the core logic that applies patch and falls back to 3-way
> could be separated out for your application. Then you could:
> (1) 'git diff HEAD' before tree-warp to preserve the user
> changes, (2) clean up the working tree to match HEAD,
At this point I get nervous since there is a potential for data loss
when something goes wrong at this point (e.g. system crash). I'm not
saying there are no places like that in Cogito now, but I generally
try to avoid them whenever possible.
> (3) warp to the other tree, and (4) fed the user change perserved
> to git-am core logic. That might give you something near optimum.
>
> About "nonsensical" objects, I am not so sure how nonsensical
> those objects you would record from the working tree
> (intermediate state) are. If you find two trees match on a path
> that has changed in the working tree, there won't be any
> conflict on that paths so it is like the user did an extra
> git-update-index on that path when no merge or warp is involved,
> from object database pollution POV; I do not personally think
> that is such a bad thing.
But if they don't match, you'll get superfluous blobs for the original
index versions which are almost certain to go away.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Photoshop CS 8.0 $59.95
From: John @ 2005-11-03 19:20 UTC (permalink / raw)
To: git
Dullness is the coming of age of seriousness.
Microsoft Visual Basic 6.0 Professional $49.95
Adobe Photoshop Elements V 2.0 $19.95
Autodesk Architectural Studio 3.0 $39.95
Macromedia Fireworks MX 2004 $29.95
Delivery method: available for instant download
http://save80software.com
^ permalink raw reply
* Re: little conundrum
From: Petr Baudis @ 2005-11-03 20:06 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511031741.20496.alan@chandlerfamily.org.uk>
Dear diary, on Thu, Nov 03, 2005 at 06:41:20PM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> told me that...
> Since I don't actually have a list of the files, I thought I would establish
> these automatically by going into each directory and doing a cg-init. So I
> now have two disjoint repositories each with their source tree in it.
>
> My next thought was to add a branch to one of them and then pull the resultant
> code over and merge it using cg-branch-add followed by a cg-update. But when
> I do that it complains that there is no common base.
>
> I tried creating an empty directory and separately merging the two versions
> with it, so that I have a common parent, but whatever I do, I can't get one
> of those nice little gitk diagrams that has any linkage between the two
> versions of the source code.
The empty directory is the good approach to do the merge, but you are
going to get a huge number of conflicts. Anyway, this is probably the
most sensible behaviour for cg-merge, so I added cg-merge -j which does
exactly that - use empty tree as a base for three-way merge.
But you actually do not want to do a merge, but:
$ cd original-version
$ cg-init
$ cd ../modified-version
$ cg-init
$ cg-branch-add orig ../original-version
$ cg-fetch orig
$ echo `cg-object-id` `cg-object-id orig` >.git/info/grafts
Voila, now your commit in 'modified' has the commit in 'original' as its
parent.
PS: And to be able to even commit the cg-merge -j, I had to back out the
git-read-tree -u usage in cg-Xlib's tree_timewarp, which made it racy as
hell - basically, it could be argued that it working _properly_ would be
a race now. Besides, keeping local changes wouldn't work, and stuff.
cg-admin-uncommit was painfully broken.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: little conundrum
From: Johannes Schindelin @ 2005-11-03 17:47 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511031741.20496.alan@chandlerfamily.org.uk>
Hi,
On Thu, 3 Nov 2005, Alan Chandler wrote:
> I would like to make myself a git repository that contains at the start,
> an initial commit of the original downloaded source code, and a second
> commit on the top of that that contains the the current state of play
> after the changes I have made.
How about this:
cd orig/
git-init-db
git-add $(find * -type f)
git-commit -m "initial"
cd ../modified
mv ../orig/.git ./
git-add $(find * -type f)
git-commit -a -m "my modifications"
Of course -- in the great tradition of this list -- totally untested.
Hth,
Dscho
^ permalink raw reply
* Re: little conundrum
From: Peter Eriksen @ 2005-11-03 19:36 UTC (permalink / raw)
To: git
In-Reply-To: <200511031930.28929.alan@chandlerfamily.org.uk>
On Thu, Nov 03, 2005 at 07:30:28PM +0000, Alan Chandler wrote:
...
> This is the same as before. It lists the modified files, but it doesn't tell
> you about any added or deleted files.
That's odd, because I get this (shortened) output with Git current:
~/peter-2.6]git-status
#
# Changed but not updated:
# (use git-update-index to mark for commit)
#
# deleted: README
# deleted: REPORTING-BUGS
# deleted: arch/mips/mips-boards/atlas/Makefile
# deleted: arch/mips/mips-boards/sead/sead_setup.c
# modified: fs/fs-writeback.c
# deleted: init/Kconfig
# deleted: init/Makefile
# deleted: init/calibrate.c
#
#
# Untracked files:
# (use "git add" to add to commit)
#
# drivers/media/MAINTAINERS
# drivers/parport/mips-boards/atlas/Makefile
# drivers/parport/mips-boards/atlas/atlas_gdb.c
# drivers/parport/mips-boards/sead/sead_setup.c
# fs/fs-writeback.c~
nothing to commit
> [I have done this manually now - originally I thought that there were quite a
> few files - but once I had stripped out things like "tags" and some spurious
> directories that were empty it ended up being only three files:-). So its
> only an intellectual exercise now:-)]
Be careful to remember to add any links. At least with Git when
I last tried importing directories containing them.
Peter
^ permalink raw reply
* Re: little conundrum
From: Alan Chandler @ 2005-11-03 19:30 UTC (permalink / raw)
To: git
In-Reply-To: <20051103191652.GA28273@bohr.gbar.dtu.dk>
On Thursday 03 Nov 2005 19:16, Peter Eriksen wrote:
>
> Perhaps something like this is better (now I actually tried it out):
>
> ]rm -rf linux-2.6/.git
> ]cp -r linux-2.6 peter-2.6
> ...Initialize a repo in linux-2.6 with cg-init or similar and commit.
> ...Remove, add and change files in peter-2.6.
> ]mv linux-2.6/.git peter-2.6/.git
> ]cd peter-2.6/
> ]git-status
>
> How does this work for you?
This is the same as before. It lists the modified files, but it doesn't tell
you about any added or deleted files.
[I have done this manually now - originally I thought that there were quite a
few files - but once I had stripped out things like "tags" and some spurious
directories that were empty it ended up being only three files:-). So its
only an intellectual exercise now:-)]
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH] RFC: proxy-command support for git://
From: Linus Torvalds @ 2005-11-03 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Collins, git
In-Reply-To: <7v8xw5h898.fsf@assigned-by-dhcp.cox.net>
On Thu, 3 Nov 2005, Junio C Hamano wrote:
> Paul Collins <paul@briny.ondioline.org> writes:
>
> > I spend some of my time using a network that only allows outgoing TCP
> > connections to certain ports, and the git-daemon port is not one of them.
> > This patch below implements an analogue to ssh's ProxyCommand feature
> > for git, as a less messy alternative to ssh port forwarding.
>
> Wonderful.
>
> > Questions:
> >
> > * Can git already do this and I just failed to notice?
>
> Maybe I just failed to notice this too, but I do not think so.
Actually, you could. TWO ways, in fact, afaik.
Just use the "ssh://host/pathname" format (or just "host:pathname") and
the GIT_SSH environment variable.
You could also override the local command-name with
git-send-pack --exec=my-local-send-program /machine/repo/path
where the "my-local-send-program" will parse /machine/repo/path thing. At
least that works with git-send-pack, but it's possible it doesn't work
with some other logic (ie "git push" might decide that it's unhappy that
/machine/repo/path doesn't exist locally because it thinks it's a local
path).
Linus
^ permalink raw reply
* Re: little conundrum
From: Peter Eriksen @ 2005-11-03 19:16 UTC (permalink / raw)
To: git
In-Reply-To: <200511031848.58040.alan@chandlerfamily.org.uk>
On Thu, Nov 03, 2005 at 06:48:57PM +0000, Alan Chandler wrote:
> On Thursday 03 Nov 2005 18:10, Peter Eriksen wrote:
[snip]
> > ]cd original
> > ]git-init-db
> > ]git-add all-the-files
> > ]git-commit -m "Initial import"
> > ]cp -rf ../modified/* .
> > ]git-status
> > ...fix things up adding and deleting files
> > ]git-commit -m "First big change
Perhaps something like this is better (now I actually tried it out):
]rm -rf linux-2.6/.git
]cp -r linux-2.6 peter-2.6
...Initialize a repo in linux-2.6 with cg-init or similar and commit.
...Remove, add and change files in peter-2.6.
]mv linux-2.6/.git peter-2.6/.git
]cd peter-2.6/
]git-status
How does this work for you?
Peter
^ permalink raw reply
* Re: [PATCH] RFC: proxy-command support for git://
From: Junio C Hamano @ 2005-11-03 18:54 UTC (permalink / raw)
To: Paul Collins; +Cc: git
In-Reply-To: <87fyqdbuab.fsf@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> I spend some of my time using a network that only allows outgoing TCP
> connections to certain ports, and the git-daemon port is not one of them.
> This patch below implements an analogue to ssh's ProxyCommand feature
> for git, as a less messy alternative to ssh port forwarding.
Wonderful.
> Questions:
>
> * Can git already do this and I just failed to notice?
Maybe I just failed to notice this too, but I do not think so.
> * Where should git_use_proxy() look? Some git configuration file?
> An environment variable? Both? Somewhere else?
My preference is put something in .git/config to describe which
proxy command (maybe the same one with different argument) to
use depending on where you are going. When you have internal
hosts and external hosts you would want this to apply only to
external hosts. Maybe you have two or more gateways and
depending on which external host you are going you may want to
use different proxied connection. On top of the config file,
making it overridable from an environment variable would be
sensible.
^ permalink raw reply
* Re: Now What?
From: Jon Loeliger @ 2005-11-03 18:51 UTC (permalink / raw)
To: Git List
In-Reply-To: <20051103014307.GA1988@pe.Belkin>
On Wed, 2005-11-02 at 19:43, Chris Shoemaker wrote:
> In general, for each common operation, it'd be nice to explain how to
> "undo".
So, I've take a stab at the "Reverse a Commit" process.
I _think_ this just about covers all the usual cases
and encompasses much of the lore already sent to the list.
I've punted (so far) on the details of the case where
you want to reverse a buried or copied commit. I've
read the howto/revert-branch-rebase.txt from Junio,
but I'm not satisfied with it. While his write up
there is very expository and comprehensive, I think it
is overkill for a "simple recipe paragraph". Also,
I was annoyed that "git revert -n commit-name" created
conflicts and the reversal and merges didn't happen
for me cleanly even though they did for Junio. I suck.
So either I don't get it, or it isn't working quite
right these days. Not sure. Advice sought.
Here's the gunk I have so far. Does this need to be
simplified? Style OK? Send us more of same! God help
us all, more ASCII art!?
You know,
jdl
Reversing Commits
-----------------
While a goal of a revision control system is to record
changes and log them via commits, it is sometimes necessary
to reverse a bogus or unwanted commit.
Making a commit in git is a reversible operation. In order
to realize the reversal, either the index needs to be
reverted to its prior state, or the contents of the files
needs to be reverted and the index updated appropriately.
Here is a rough flow chart to help you. Discussion of
the individual cases, along with example commands, follows.
+----------------------+
| Oops! I didn't mean |
| to make that commit! |
+----------------------+
|
|
|
V
^
/ \
/ Does \
/ anyone \ "Live with it"
< else have a > -----------------+
\ copy of / Yes |
\ commit/ |
\ ? / |
V |
| No |
| |
| |
V |
^ |
/ \ |
/ Is \ V
/ commit \ No +--------------------+
< at top of > ------------> | Generate and apply |
\ HEAD / Ponder | a reverse patch or |
\ ? / Using StGit | use git-revert |
\ / +--------------------+
V
| Yes
|
|
V
^
/ \
/ Are \
/ there \ No +------------------------+
< local dir > ------------> | # Blow it all away |
\ mods / | git reset --hard HEAD^ |
\ ? / +------------------------+
\ / |
V |
|
| Yes |
| |
| |
V |
+----------------------------+ V
| # I want to recommit it | +----------------------+
| git reset --soft HEAD^ | | # Maybe cleanup some |
| | --> | git prune |
| # edit/fixup files by hand | +----------------------+
| # maybe git-add new files |
| |
| git commit -a -c ORIG_HEAD |
+----------------------------+
First, answer this question: Is it possible that someone
else has a copy of this repository with the faulty commit?
If so, or if the bogus commit is not the most recent commit
on the head, it is very likely the correct course of action
is to simply make a new commit that reverses the prior, bogus
commit.
If there is no other copy of the repository with the bad
commit, then fairly simple steps can be taken to reverse
or remove the bogus commit, but it depends on the state
of your working directory and your intent.
Reverse a buried or copied commit
---------------------------------
FIXME: While the "git diff | apply" works cleanly,
the "git revert" didn't. Ponder.
Use git show-branch to determine the patch name you
would like to revert.
# "c" is some commit name, c^ its parent
% git diff c c^ | git apply
% git commit -m "Reverting commit...."
Versus:
% git revert -n c
[FIXME: Reference howto/revert-branch-rebase.txt]
If you find yourself doing this sort of apply-then-revert
operation frequently, you might want to consider the
StGit tool [FIXME: Reference StGit].
I didn't mean to do that commit! (And I want to blow it away!)
-------------------------------------------------------------
If no other repository or copy of the bogus commit exists,
you can easily remove the immediately prior commit on a
head by simply reverting the index to its prior state.
First, make sure that your working tree matches the
latest commit you are about to undo:
# Should be no diffs here
% git diff HEAD
# Should be the bogus commit, forward:
% git diff HEAD^
# Should be the bogus commit, reverse:
% git diff HEAD HEAD^
If that all looks fine, revert the index:
# Revert the index to its prior (pre-commit) state
% git reset --hard HEAD^
Be sure you have no other modified files in your working
directory as they will be overwritten by this command.
Entirely new files that are not mentioned in the index will
be left untouched. However, files that are tracked in the
index will be reverted to their HEAD^ state.
I didn't mean to do that commit! (And I want to recommit it.)
-------------------------------------------------------------
After making a commit and finding a mistake either in the
checked-in files or commit log message), you can fix it up
by doing this:
# Revert the index to its prior (pre-commit) state
% git reset --soft HEAD^
# Fix the checked-in files using your favorite editor
# Maybe do git-add file(s) that was forgotten, etc.
% git commit -a -c ORIG_HEAD
The --soft reset leaves the working tree files intact
and just rewinds the .git/HEAD to whatever commit you specify.
Here, the immediately prior index state, HEAD^. As a side
effect it stores the original .git/HEAD in .git/ORIG_HEAD.
The -a flag to git-commit asks for all paths in the index
to be updated. The lowercase -c flag to git-commit requests
an opportunity to re-edit the prior commit log message.
Cleaning Up After A Reverted Commit
-----------------------------------
If you have reverted a commit using either "git reset --hard"
or "git reset --soft", you will very likely have created
at least one dangling commit and possibly some dangling blobs
as well. If you are certain you no longer need these objects,
you can check for fuzz and prune them:
# Fuzz check
% git fsck-objects
# Maybe inspect the danglers using git-cat-file
# Remove the danglers, they aren't needed
$ git prune
^ permalink raw reply
* Re: little conundrum
From: Alan Chandler @ 2005-11-03 18:48 UTC (permalink / raw)
To: git
In-Reply-To: <20051103181002.GA26437@bohr.gbar.dtu.dk>
On Thursday 03 Nov 2005 18:10, Peter Eriksen wrote:
> On Thu, Nov 03, 2005 at 05:41:20PM +0000, Alan Chandler wrote:
> > I have a little problem I am trying to solve. Tried a few things and got
> > nowhere, so I thought I would ask here.
> >
> > I have two directories one of which contains a tree of source code that
> > was an original software package that I downloaded. The other contains
> > the result of some unfinished - but quite substancial changes that I had
> > made to that source code. Since this was some time ago, I don't have any
> > records, but it is quite possible that I added and removed quite a few
> > files.
> What I read from this, is that you could do something like (with Git,
> but I suppose Cogito is very similar):
>
> ]cd original
> ]git-init-db
> ]git-add all-the-files
> ]git-commit -m "Initial import"
> ]cp -rf ../modified/* .
> ]git-status
> ...fix things up adding and deleting files
> ]git-commit -m "First big change
>
> The point is, I think git-status will tell you about any
> modifications you have made by just overwriting the original
> tree with the modified one.
The advantage of cg-init (as opposed git-init-db) is that it finds all the
files to add.
I just did a quick trial of this, and it appears that git-status does not
notice deleted or added files.
That is one of the major issues that was worrying me - that I didn't miss any
of those.
There is a manual workaround - I have just run up kdiff3 (from kde) on the two
directories and it is showing 59 file differences (as opposed to the 21
reported by git-status). So I could go down them one by one and deal with
them.
But I was hoping there was an automated method:-(
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 18:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Peter Eriksen, git, Jon Loeliger
In-Reply-To: <Pine.LNX.4.64.0511030926020.27915@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And that's exactly what "git reset --hard" is there for. It will reset to
> the old head of the branch you are on (ie HEAD), and get rid of everything
> that was done to the tree.
OK, then let's rewrite the procedure using 'reset --hard'. Then
we do not have to use 'checkout -f' afterwards. The advantage
of this approach is that 'reset --hard' would remove the new
files the failed merge might have left in your working tree,
while using 'checkout -f' would.
What now? Depends on what you wanted to do. If what you wanted
to do was to merge my "master" to your "maint", then you would
resolve the conflicts by hand, but probably that was not what
you wanted to do.
After that pull, your repository is in this state:
. the index file and working tree is somewhere between your
"maint" and my "master". "somewhere between" is because the
merge obviously failed.
. the "maint" head has not moved. Your .git/HEAD points at the
"maint" branch.
. the "origin" head points at my latest "master" head.
First thing is to bring your tree to a known state, to make
recovery easier.
$ git reset --hard
would match your working tree to your .git/HEAD, i.e. your
"maint".
If you keep a copy of my "master" plus zero or more of your own
development in your "master" branch, and what you wanted to do
was to build my "master" plus those developments of your own,
then:
$ git checkout master
$ git pull . origin
If your "master" is just a vanilla copy of my "master", then
this pull would result in a fast forward, and "master" and
"origin" will point at the same commit after this pull
operation. Otherwise, you would merge your changes and my
"master" updates into your "master" branch.
If what you wanted to do was to build my "master" vanilla, then:
$ git checkout origin
because your remotes/origin says "origin" is meant to be a
straight copy of my "master".
A good habit to get into is, before pulling, make sure:
. your index matches your HEAD.
. the local modification (i.e. what git-diff-files would report)
is something you do not mind losing.
. you are on the right branch you want to pull into (check with
"git branch").
^ permalink raw reply
* Re: little conundrum
From: Peter Eriksen @ 2005-11-03 18:10 UTC (permalink / raw)
To: git
In-Reply-To: <200511031741.20496.alan@chandlerfamily.org.uk>
On Thu, Nov 03, 2005 at 05:41:20PM +0000, Alan Chandler wrote:
> I have a little problem I am trying to solve. Tried a few things and got
> nowhere, so I thought I would ask here.
>
> I have two directories one of which contains a tree of source code that was an
> original software package that I downloaded. The other contains the result
> of some unfinished - but quite substancial changes that I had made to that
> source code. Since this was some time ago, I don't have any records, but it
> is quite possible that I added and removed quite a few files.
>
> I would like to make myself a git repository that contains at the start, an
> initial commit of the original downloaded source code, and a second commit on
> the top of that that contains the the current state of play after the changes
> I have made.
What I read from this, is that you could do something like (with Git,
but I suppose Cogito is very similar):
]cd original
]git-init-db
]git-add all-the-files
]git-commit -m "Initial import"
]cp -rf ../modified/* .
]git-status
...fix things up adding and deleting files
]git-commit -m "First big change
The point is, I think git-status will tell you about any
modifications you have made by just overwriting the original
tree with the modified one.
Peter
^ permalink raw reply
* little conundrum
From: Alan Chandler @ 2005-11-03 17:41 UTC (permalink / raw)
To: git
I have a little problem I am trying to solve. Tried a few things and got
nowhere, so I thought I would ask here.
I have two directories one of which contains a tree of source code that was an
original software package that I downloaded. The other contains the result
of some unfinished - but quite substancial changes that I had made to that
source code. Since this was some time ago, I don't have any records, but it
is quite possible that I added and removed quite a few files.
I would like to make myself a git repository that contains at the start, an
initial commit of the original downloaded source code, and a second commit on
the top of that that contains the the current state of play after the changes
I have made.
Since I don't actually have a list of the files, I thought I would establish
these automatically by going into each directory and doing a cg-init. So I
now have two disjoint repositories each with their source tree in it.
My next thought was to add a branch to one of them and then pull the resultant
code over and merge it using cg-branch-add followed by a cg-update. But when
I do that it complains that there is no common base.
I tried creating an empty directory and separately merging the two versions
with it, so that I have a common parent, but whatever I do, I can't get one
of those nice little gitk diagrams that has any linkage between the two
versions of the source code.
Is there an approach I could take to achieve what I want?
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: Now What?
From: Peter Eriksen @ 2005-11-03 17:30 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511031151070.25300@iabervon.org>
On Thu, Nov 03, 2005 at 12:05:42PM -0500, Daniel Barkalow wrote:
> On Thu, 3 Nov 2005, Junio C Hamano wrote:
>
> > "Peter Eriksen" <s022018@student.dtu.dk> writes:
> >
> > > Here's one I've done too many times:
> > >
> > > ~/git/git-core]cat .git/remotes/origin
> > > URL: git://git.kernel.org/pub/scm/git/git.git
> > > Pull: master:origin
> > >
> > > ~/git/git-core]git-checkout maint
> > > ~/git/git-core]git pull
> >
> > You are merging my master into your "maint", probably a copy of
> > my (previous) maint.
>
> I think the situation is that he really wanted to update master, but
> forgot that he was on the maint branch. So now he's in a merge of things
> he didn't actually want to merge and wants to get back to not having junk
> all over the place (some files that need to be merged, some files that
> have been merged, new files, removed files, etc).
I really should have stated that from the beginning. Yes, I forgot, I
had checked out some other branch and thought (the first I times assumed)
that it would merge into master. So it's really just an accident,
which I would think, is not that uncommon for newcommers.
Peter
^ permalink raw reply
* Re: Now What?
From: Linus Torvalds @ 2005-11-03 17:27 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Peter Eriksen, git, Jon Loeliger
In-Reply-To: <Pine.LNX.4.64.0511031151070.25300@iabervon.org>
On Thu, 3 Nov 2005, Daniel Barkalow wrote:
>
> I think the situation is that he really wanted to update master, but
> forgot that he was on the maint branch. So now he's in a merge of things
> he didn't actually want to merge and wants to get back to not having junk
> all over the place (some files that need to be merged, some files that
> have been merged, new files, removed files, etc).
And that's exactly what "git reset --hard" is there for. It will reset to
the old head of the branch you are on (ie HEAD), and get rid of everything
that was done to the tree.
Linus
^ permalink raw reply
* Re: Now What?
From: Linus Torvalds @ 2005-11-03 17:25 UTC (permalink / raw)
To: Peter Eriksen; +Cc: Jon Loeliger, git
In-Reply-To: <20051103083840.GA28300@ebar091.ebar.dtu.dk>
On Thu, 3 Nov 2005, Peter Eriksen wrote:
>
> Here's one I've done too many times:
>
> ~/git/git-core]cat .git/remotes/origin
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: master:origin
>
> ~/git/git-core]git-checkout maint
> ~/git/git-core]git pull
> Unpacking 222 objects
> 100% (222/222) done
> * committish: 9534f40bc42dd826cc26c8c8c84f6a8a5fc569f6
> branch 'master' of git://git.kernel.org/pub/scm/git/git
> * refs/heads/origin: storing branch 'master' of
> * git://git.kernel.org/pub/scm/git/git
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
> Nope.
> Trying simple merge.
> Simple merge failed, trying Automatic merge.
> Auto-merging Documentation/tutorial.txt.
> Auto-merging Makefile.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in Makefile.
> Auto-merging apply.c.
> Auto-merging cache.h.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in cache.h.
> Auto-merging clone-pack.c.
> Auto-merging connect.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in connect.c.
> Auto-merging daemon.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in daemon.c.
> Auto-merging debian/changelog.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in debian/changelog.
> Auto-merging fetch-pack.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in fetch-pack.c.
> Auto-merging git-branch.sh.
> Auto-merging git-checkout.sh.
> Auto-merging git-clone.sh.
> Auto-merging git-cvsimport.perl.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in git-cvsimport.perl.
> Auto-merging git-fetch.sh.
> Auto-merging git-parse-remote.sh.
> Auto-merging git-tag.sh.
> Auto-merging quote.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in quote.c.
> Auto-merging quote.h.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in quote.h.
> Auto-merging refs.c.
> Auto-merging rev-list.c.
> Auto-merging send-pack.c.
> Auto-merging sha1_name.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in sha1_name.c.
> Auto-merging upload-pack.c.
> merge: warning: conflicts during merge
> ERROR: Merge conflict in upload-pack.c.
> fatal: merge program failed
> Automatic merge failed; fix up by hand
>
> Indeed, what now?
You can do two things:
a) decide not to merge at all:
git reset --hard
and you're done. This is what you want to do when you just pulled the
wrong branch, for example.
IF you pulled the right branch, and you knew you had other changes through
other pulls or because you just had done your own development, you want to
look at:
b) Try to resolve the merge. Do a "git diff" and look what was unresolved
(by looking for those bog-standard resolve conflict markers like
"<<<<< old ===== new >>>>>".
Edit the conflicts by hand to what you want them to be, and do
git commit --all
to commit your manual merge.
Note that if you start doing (b) and you decide it's too much for you, you
can always go back to (a) in the end and ask for help from the people
involved.
Linus
^ permalink raw reply
* Re: Now What?
From: Daniel Barkalow @ 2005-11-03 17:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Eriksen, git, Jon Loeliger
In-Reply-To: <7v4q6uhx0a.fsf@assigned-by-dhcp.cox.net>
On Thu, 3 Nov 2005, Junio C Hamano wrote:
> "Peter Eriksen" <s022018@student.dtu.dk> writes:
>
> > Here's one I've done too many times:
> >
> > ~/git/git-core]cat .git/remotes/origin
> > URL: git://git.kernel.org/pub/scm/git/git.git
> > Pull: master:origin
> >
> > ~/git/git-core]git-checkout maint
> > ~/git/git-core]git pull
>
> You are merging my master into your "maint", probably a copy of
> my (previous) maint.
I think the situation is that he really wanted to update master, but
forgot that he was on the maint branch. So now he's in a merge of things
he didn't actually want to merge and wants to get back to not having junk
all over the place (some files that need to be merged, some files that
have been merged, new files, removed files, etc).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] RFC: proxy-command support for git://
From: Paul Collins @ 2005-11-03 15:55 UTC (permalink / raw)
To: git
I spend some of my time using a network that only allows outgoing TCP
connections to certain ports, and the git-daemon port is not one of them.
This patch below implements an analogue to ssh's ProxyCommand feature
for git, as a less messy alternative to ssh port forwarding. One can
use it to ssh to a bastion host and netcat to the destination:
$ cat ~/bin/my-git-proxy-command
#!/bin/sh
exec ssh bastionhost nc "$1" "$2"
I've done a few pulls and a clone with it, and it seems to work.
Questions:
* Can git already do this and I just failed to notice?
* Where should git_use_proxy() look? Some git configuration file?
An environment variable? Both? Somewhere else?
It also needs to support non-default ports and probably other things I missed.
diff --git a/connect.c b/connect.c
index c2badc7..646e26f 100644
--- a/connect.c
+++ b/connect.c
@@ -448,6 +448,40 @@ static int git_tcp_connect(int fd[2], co
#endif /* NO_IPV6 */
+static int git_proxy_connect(int fd[2], const char *prog, char *host, char *path)
+{
+ char *command = "my-git-proxy-command"; /* FIXME: cf. git_use_proxy() */
+ char *port = STR(DEFAULT_GIT_PORT);
+ int pipefd[2][2];
+ pid_t pid;
+
+ if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
+ die("unable to create pipe pair for communication");
+ pid = fork();
+ if (!pid) {
+ dup2(pipefd[1][0], 0);
+ dup2(pipefd[0][1], 1);
+ close(pipefd[0][0]);
+ close(pipefd[0][1]);
+ close(pipefd[1][0]);
+ close(pipefd[1][1]);
+ execlp(command, command, host, port, NULL);
+ die("exec failed");
+ }
+ fd[0] = pipefd[0][0];
+ fd[1] = pipefd[1][1];
+ close(pipefd[0][1]);
+ close(pipefd[1][0]);
+ packet_write(fd[1], "%s %s\n", prog, path);
+ return pid;
+}
+
+static int git_use_proxy(void)
+{
+ /* FIXME: look for the proxy command somewhere - repo's config? environment? */
+ return 1;
+}
+
/*
* Yeah, yeah, fixme. Need to pass in the heads etc.
*/
@@ -482,8 +516,11 @@ int git_connect(int fd[2], char *url, co
}
}
- if (protocol == PROTO_GIT)
+ if (protocol == PROTO_GIT) {
+ if (git_use_proxy())
+ return git_proxy_connect(fd, prog, host, path);
return git_tcp_connect(fd, prog, host, path);
+ }
if (pipe(pipefd[0]) < 0 || pipe(pipefd[1]) < 0)
die("unable to create pipe pair for communication");
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related
* Re: [PATCH] cogito: make tutorial-script a testsuite
From: Petr Baudis @ 2005-11-03 10:36 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Horst H. von Brand
In-Reply-To: <1130980582.20017.14.camel@dv>
Dear diary, on Thu, Nov 03, 2005 at 02:16:22AM CET, I got a letter
where Pavel Roskin <proski@gnu.org> told me that...
> Documentation/tutorial-script/script.sh can be used as a testsuite.
> Errors should cause the script to exit. Unexpected success should be
> treated like an error. Successful completion should be reported.
Thanks, applied. Perhaps we could invoke it during make test as well...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 10:00 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git, Jon Loeliger
In-Reply-To: <20051103083840.GA28300@ebar091.ebar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> Here's one I've done too many times:
>
> ~/git/git-core]cat .git/remotes/origin
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: master:origin
>
> ~/git/git-core]git-checkout maint
> ~/git/git-core]git pull
You are merging my master into your "maint", probably a copy of
my (previous) maint.
What now? Depends on what you wanted to do. If what you wanted
to do was to merge my "master" to your "maint", then you would
resolve the conflicts by hand, but probably that was not what
you wanted to do.
After that pull, your repository is in this state:
. the index file and working tree is somewhere between your
"maint" and my "master". "somewhere between" is because the
merge obviously failed.
. the "maint" head has not moved. Your .git/HEAD points at the
"maint" branch.
. the "origin" head points at my latest "master" head.
If you keep a copy of my "master" plus zero or more of your own
development in your "master" branch, and what you wanted to do
was to build my "master" plus those developments of your own,
then:
$ git checkout -f master
$ git pull . origin
If your "master" is just a vanilla copy of my "master", then
this pull would result in a fast forward, and "master" and
"origin" will point at the same commit after this pull
operation. Otherwise, you would merge your changes and my
"master" updates into your "master" branch.
If what you wanted to do was to build my "master" vanilla, then:
$ git checkout -f origin
because your remotes/origin says "origin" is meant to be a
straight copy of my "master".
A good habit to get into is, before pulling, make sure:
. your index matches your HEAD.
. the local modification (i.e. what git-diff-files would report)
is something you do not mind losing.
. you are on the right branch you want to pull into (check with
"git branch").
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 9:00 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: git
In-Reply-To: <20051103014307.GA1988@pe.Belkin>
Chris Shoemaker <c.shoemaker@cox.net> writes:
> "I cloned a remote repo. Then I pulled a branch from the remote repo
> and it started changing all the these files. I paniced and hit
> ctrl-c. Doh! I should have checked out the branch locally before
> pulling. Now what? How can I recover without cloning the repo
> again?"
Although I am not sure what this example is about,...
> In general, for each common operation, it'd be nice to explain how to
> "undo".
I think this makes sense.
^ permalink raw reply
* Re: Now What?
From: Peter Eriksen @ 2005-11-03 8:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EXTw5-00063o-Gt@jdl.com>
On Wed, Nov 02, 2005 at 07:30:37PM -0600, Jon Loeliger wrote:
...
> I think one of the most crucial aspects that needs to be
> covered well is the "Merge Failed" problem. So, for starters,
> I'd like to get your suggestions on this particular issue.
> I know when I see the dreaded "merge by hand" message I
> often sit and stare, pondering "Now what?"
Here's one I've done too many times:
~/git/git-core]cat .git/remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin
~/git/git-core]git-checkout maint
~/git/git-core]git pull
Unpacking 222 objects
100% (222/222) done
* committish: 9534f40bc42dd826cc26c8c8c84f6a8a5fc569f6
branch 'master' of git://git.kernel.org/pub/scm/git/git
* refs/heads/origin: storing branch 'master' of
* git://git.kernel.org/pub/scm/git/git
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Trying simple merge.
Simple merge failed, trying Automatic merge.
Auto-merging Documentation/tutorial.txt.
Auto-merging Makefile.
merge: warning: conflicts during merge
ERROR: Merge conflict in Makefile.
Auto-merging apply.c.
Auto-merging cache.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in cache.h.
Auto-merging clone-pack.c.
Auto-merging connect.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in connect.c.
Auto-merging daemon.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in daemon.c.
Auto-merging debian/changelog.
merge: warning: conflicts during merge
ERROR: Merge conflict in debian/changelog.
Auto-merging fetch-pack.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fetch-pack.c.
Auto-merging git-branch.sh.
Auto-merging git-checkout.sh.
Auto-merging git-clone.sh.
Auto-merging git-cvsimport.perl.
merge: warning: conflicts during merge
ERROR: Merge conflict in git-cvsimport.perl.
Auto-merging git-fetch.sh.
Auto-merging git-parse-remote.sh.
Auto-merging git-tag.sh.
Auto-merging quote.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in quote.c.
Auto-merging quote.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in quote.h.
Auto-merging refs.c.
Auto-merging rev-list.c.
Auto-merging send-pack.c.
Auto-merging sha1_name.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in sha1_name.c.
Auto-merging upload-pack.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in upload-pack.c.
fatal: merge program failed
Automatic merge failed; fix up by hand
Indeed, what now?
Regards,
Peter
^ permalink raw reply
* Re: Now What?
From: Junio C Hamano @ 2005-11-03 8:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EXTw5-00063o-Gt@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> I feel that an explanation of all of the behind-the-scripts-
> in-.git communication files is needed. In particular these:
>
> FETCH_HEAD
> MERGE_HEAD
> LAST_MERGE
> MERGE_MSG
>
> These need to be mentioned and explained because they
> frequently form exactly the critical missing link or
> starting point after a failed fetch or merge.
I am not so sure if it would help to know details of the above
four files to answer "Now What" question, but I'll try to
describe them near the end of this message.
Before that, here is a cookbook failed pull/merge resolution
procedure.
$ git pull some-where
Gaah ... resolve by hand.
Oops, it failed. Now what?
First, if your index did not match your HEAD before
pulling/merging, the merge strategies will refuse to merge in
the changes and would fail without touching your working tree
(so you would not even see "resolve by hand" message). If you
want to proceed, you need to somehow match your HEAD and your
index to retry. There are two possibilities.
(1) if you were deep in a middle of something, snapshot your
changes and rewind the current tree.
$ git commit -a -m 'WIP'
$ git branch save-wip
$ git reset --hard HEAD^
and then retry merge or pull. Later you would want to
resurrect what you did from save-wip branch (e.g. "git diff
save-wip^ save-wip | git apply" after finishing your
merge).
(2) if you did not have much worth saving, just rewind the
changes. Optionally you could save the diff just in case.
$ git diff HEAD >tmp-wip.diff
$ git reset --hard
and then retry merge or pull.
Now that case is out of our way, I'll discuss the case where
your index did match your HEAD from here on. You pulled from
remote, merge strategy tried to do its work, and did not find a
clean automerge.
At this point, the automerge procedure would have already
updated your index for paths that cleanly merged. The rest are
left in your working tree, so this diff would show what remains
to be resolved:
$ git diff
You would most likely see some <<<< ==== >>>> conflict markers.
Resolving them by hand is hopefully something familiar to CVS or
SVN migrants, so "Now what" document may not have to talk about
what these conflict markers mean ("between <<<< and ==== are
your version, between ==== and >>>> are their version", or
something like that --- I may be getting this particular detail
wrong in this sentence, so you should check).
After resolving them by hand, you would want to see what got
changed from _your_ version for sanity checking, because you are
hopefully more familiar with your version than theirs, and
reading diff between theirs might be more difficult. So check
$ git diff HEAD
to see what changes this pull brought in, including the conflict
resolution you just did. On the other hand,
$ git diff MERGE_HEAD
would show diff from their head, so you would see what you did
to their tree.
After checking the diffs, if things look OK, compiling and
testing is the same procedure as you would normally do before
making any commit. Then
$ git commit -a
(as usual, you can drop '-a' if you manually 'git-update-index'
all the necessary paths before this step) would give you the
regular commit message editor, with a reminder "you are
committing a merge", with prepared message "merge from
some-where repository". Edit it and exit the editor normally to
make the merge commit, and you are done.
Now to the communication files.
> FETCH_HEAD
This file lists refs the git-fetch command (run from git-pull)
retrieved from the remote. Usually it marks everything but one
as 'not-for-merge'. The one that is not marked as
'not-for-merge' is the commit you are merging into the current
head. This is not looked at by the merge machinery, but
git-pull uses it to decide which commits to pass to git-merge.
> MERGE_HEAD
This is present only after a failed automerge, by git-merge, and
lists the commits that you are merging into the current head
(typically only one) -- the same as the ones not marked as
'not-for-merge' in FETCH_HEAD, because this file records the
commits given to git-merge.
> LAST_MERGE
This is more or less historical curiosity and only git-resolve
uses it. Records almost the same information as MERGE_HEAD.
> MERGE_MSG
This is created by git-pull from FETCH_HEAD to format a human
readable autocommit log.
> Finally, a procedure or style question. Should this
> write-up be in the form of a structured FAQ? A stand-alone
> expository document?
One useful thing would be to have a cut&paste ready example that
would cover constructing two branches/repos, pulling a branch
from one to the other and causing an actual conflict, and show
how to resolve it and make a commit, in a section in Tutorial.
I think we already have something like that there.
Another good thing would be, after proofreading this message and
making necessary corrections, send it as a patch form to add it
as a new file under Documentation/howto/.
^ permalink raw reply
* Problem cloning the Linux history tree
From: Marcel Holtmann @ 2005-11-03 8:56 UTC (permalink / raw)
To: git; +Cc: Thomas Gleixner
Hi guys,
I have some problems cloning the Linux history tree from Thomas Gleixner
over the HTTP transport. The rsync transport seems to work.
# cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
defaulting to local storage area
09:53:02 URL:http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/HEAD [41/41] -> "refs/heads/.origin-fetching" [1]
Getting alternates list
Getting pack list
error: The requested URL returned error: 404
error: Unable to find e7e173af42dbf37b1d946f9ee00219cb3b2bea6a under http://www.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/
Cannot obtain needed object e7e173af42dbf37b1d946f9ee00219cb3b2bea6a
while processing commit 0000000000000000000000000000000000000000.
cg-fetch: objects fetch failed
cg-clone: fetch failed
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox