* Re: Puzzled by a t9500 test failure
From: Junio C Hamano @ 2008-10-14 0:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081013234851.GY4856@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> With recent tip of 'master':
>>
>> $ make
>> $ mkdir t/trash
>> $ cd t && sh t9500-*.sh -i
>>
>> fails at the very first test. Can anybody figure out why?
>
> Hmmph. Near as I can tell its because gitweb.log has this in it:
>
> $ cat gitweb.log
> [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in scalar chomp at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 1811.
> [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in addition (+) at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 3772.
> HASH..
>
> The test does a grep for '[[]' and if it matches, fails. I'm not
> sure why this started showing up now. Obviously I merged something
> that failed the test suite, but I was pretty sure I had run the full
> set before publishing anything.
Nothing as far as I can tell changed while you were the pumpking.
I was just wondering why the presense of that extra, should-be-unused,
t/trash directory affects the outcome of the test.
^ permalink raw reply
* Re: Puzzled by a t9500 test failure
From: Shawn O. Pearce @ 2008-10-14 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vhc7g8257.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> With recent tip of 'master':
> >>
> >> $ make
> >> $ mkdir t/trash
> >> $ cd t && sh t9500-*.sh -i
> >>
> >> fails at the very first test. Can anybody figure out why?
> >
> > Hmmph. Near as I can tell its because gitweb.log has this in it:
> >
> > $ cat gitweb.log
> > [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in scalar chomp at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 1811.
> > [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in addition (+) at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 3772.
> > HASH..
> >
> > The test does a grep for '[[]' and if it matches, fails. I'm not
> > sure why this started showing up now. Obviously I merged something
> > that failed the test suite, but I was pretty sure I had run the full
> > set before publishing anything.
>
> Nothing as far as I can tell changed while you were the pumpking.
>
> I was just wondering why the presense of that extra, should-be-unused,
> t/trash directory affects the outcome of the test.
Seriously?
Oh. Some time with strace later...
Its because Perl totally borked the $projectroot path when it was
looking at $GIT_DIR/ctags. $GIT_DIR has a space in the path and
Perl bound the first aprt, opened it, but cannot open the second
part of the $GIT_DIR/ctags string because it doesn't exist.
The code in question is the new tag cloud code in gitweb that
Peter added. So bisect is still correct.
My guess is its the code in git_get_project_ctags(), around
l.1804-1816.
--
Shawn.
^ permalink raw reply
* [ANNOUNCE] Git User's Survey 2008 has closed
From: Jakub Narebski @ 2008-10-14 0:25 UTC (permalink / raw)
To: git, linux-kernel, Petr Baudis, Scott Chacon, webmaster, J.H.,
"H. Peter
Cc: Petr Baudis
In-Reply-To: <200808312329.17312.jnareb@gmail.com>
Hi all,
Git User's Survey 2008 ended at the end of Monday, 13 October 2008,
around 23:45 CEST (GMT+0200).
Could you then *take down* notice about Git User's Survey 2008,
and/or perhaps announce that it is closed?
Beginnings of Survey summary should be available soon at
http://git.or.cz/gitwiki/GitSurvey2008
Currently you can get there raw data (individual responses). One can
find there also to online analysis (on Survs.com) and beginnings of
partial survey summary (send to git mailing list).
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] Fix testcase failure when extended attributes are in use
From: Deskin Miller @ 2008-10-14 2:10 UTC (permalink / raw)
To: git; +Cc: gitster, heikki.orsila
In-Reply-To: <20081011154107.GA14994@riemann.deskinm.fdns.net>
06cbe855 (Make core.sharedRepository more generic, 2008-04-16) made
several testcases in t1301-shared-repo.sh which fail if on a system
which creates files with extended attributes (e.g. SELinux), since ls
appends a '+' sign to the permission set in such cases. This fixes the
testcase to strip any such sign prior to verifying the permission set.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
...and then I discovered Documentation/CodingGuidelines: no ? in regular
expressions. I really need to learn these shell variable-manipulation
builtins.
Apologies if for some reason the previous version got used, I haven't seen it
anywhere, however.
Deskin Miller
t/t1301-shared-repo.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index dc85e8b..4d2db62 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -84,6 +84,7 @@ do
git update-server-info &&
actual="$(ls -l .git/info/refs)" &&
actual=${actual%% *} &&
+ actual=${actual%+} &&
test "x$actual" = "x-$y" || {
ls -lt .git/info
false
@@ -97,6 +98,7 @@ do
git update-server-info &&
actual="$(ls -l .git/info/refs)" &&
actual=${actual%% *} &&
+ actual=${actual%+} &&
test "x$actual" = "x-$x" || {
ls -lt .git/info
false
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* Git 1.6.0.2, Submodules and MacOSX Leopard
From: Lars Hoss @ 2008-10-14 6:53 UTC (permalink / raw)
To: git
Greetings everyone!
Last night I played around with submodules on MacOSX Leopard using Git
1.6.0.2.
And it seems there is a bug.
If I add a submodule like this:
git submodule add /Users/lars/tmp/git_test/foo_lib/ lib
It says:
Initialized empty Git repository in /Users/lars/tmp/git_test/
sample_app/lib/.git/
And I can see the lib folder. So far so good. But when I do a git
status it says:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: lib
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# lib/
So why is lib listed under untracked files?
I did a quick test on my Linux server and there it worked as expected.
Which means that lib wasn't listed under
untracked files. Then again I use an older version of git on my Linux
box (1.5.x).
Yours,
Lars
^ permalink raw reply
* View remote logs?
From: Todd A. Jacobs @ 2008-10-14 7:19 UTC (permalink / raw)
To: git
I've Googled around, and tried some experiments with likely-looking
tools like git log, git diff, and git ls-remote, but they only seem to
operate on the local repository. In particular, there doesn't seem to be
an obvious way to view the commit logs on a remote repository without
pulling it first.
On an intuitive level, it seems like "git log origin" would allow me to
see what someone has committed to a remote repository so I can decide
whether it's something I want to pull. Even something like "git diff
HEAD origin" would let me know if there were changes I might want to
pull before doing so.
Am I missing something obvious? Is it possible to use the CLI to view
remote logs, or is the only choice to pull everything?
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: View remote logs?
From: Jeff King @ 2008-10-14 8:10 UTC (permalink / raw)
To: git
In-Reply-To: <20081014071907.GP16999@penguin.codegnome.org>
On Tue, Oct 14, 2008 at 12:19:07AM -0700, Todd A. Jacobs wrote:
> I've Googled around, and tried some experiments with likely-looking
> tools like git log, git diff, and git ls-remote, but they only seem to
> operate on the local repository. In particular, there doesn't seem to be
> an obvious way to view the commit logs on a remote repository without
> pulling it first.
Remember that pull is really "fetch + merge". So you can do just the
fetch part without affecting your local branches.
> On an intuitive level, it seems like "git log origin" would allow me to
> see what someone has committed to a remote repository so I can decide
It does. It just uses the remote tracking branch for "origin" instead of
contacting the remote.
> whether it's something I want to pull. Even something like "git diff
> HEAD origin" would let me know if there were changes I might want to
> pull before doing so.
And that works, too. Once fetched, you can use "origin" as you would any
other ref.
-Peff
^ permalink raw reply
* Re: View remote logs?
From: Michael J Gruber @ 2008-10-14 8:21 UTC (permalink / raw)
To: git
In-Reply-To: <20081014071907.GP16999@penguin.codegnome.org>
Todd A. Jacobs venit, vidit, dixit 14.10.2008 09:19:
> I've Googled around, and tried some experiments with likely-looking
> tools like git log, git diff, and git ls-remote, but they only seem to
> operate on the local repository. In particular, there doesn't seem to be
> an obvious way to view the commit logs on a remote repository without
> pulling it first.
>
> On an intuitive level, it seems like "git log origin" would allow me to
> see what someone has committed to a remote repository so I can decide
> whether it's something I want to pull. Even something like "git diff
> HEAD origin" would let me know if there were changes I might want to
> pull before doing so.
>
> Am I missing something obvious? Is it possible to use the CLI to view
> remote logs, or is the only choice to pull everything?
You can always fetch (rather than pull) and then decide whether to pull
(i.e. merge or rebase FETCH_HEAD) or not.
The problem with "remote log" is that log can show diffstats, full diffs
etc, so that it would need all new objects anyways.
If you want to avoid fetching new objects the only way is to run git log
etc. on the remote side. You can do this with ssh, but the other
transports (git:, http:) don't support this.
Michael
^ permalink raw reply
* [BUG?] git remote rm repo nukes local refs for mirror repo
From: Michael J Gruber @ 2008-10-14 9:05 UTC (permalink / raw)
To: Git Mailing List
I just noticed the hard way that "git remote rm repo" nukes all local
(mirrored) refs if repo had been setup with "git remote add --mirror
repo url".
Some may argue that this behaviour fits the description "deletes all
remote tracking branches" but I would claim it does not: mirrored
branches are not remote tracking branches in the proper sense.
So:
- Is this behaviour intended?
- If yes, how else would I remove a remote mirror configuration without
destroying a local repo? git config, I know, but that can't be the way.
Michael
Technical:
remote_find_tracking() in remote.c returns "branch" as the remote
tracking branch of "branch" (itself) in a mirror setup. Is this the
right thing to do?
^ permalink raw reply
* Re: [BUG?] git remote rm repo nukes local refs for mirror repo
From: Johannes Schindelin @ 2008-10-14 9:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <48F460DB.9030209@drmicha.warpmail.net>
Hi,
On Tue, 14 Oct 2008, Michael J Gruber wrote:
> I just noticed the hard way that "git remote rm repo" nukes all local
> (mirrored) refs if repo had been setup with "git remote add --mirror
> repo url".
>
> Some may argue that this behaviour fits the description "deletes all
> remote tracking branches" but I would claim it does not: mirrored
> branches are not remote tracking branches in the proper sense.
Count me into the former group. If you set up a "--mirror" repository, it
defeats the purpose to mix that with _true_ local branches.
I'd color this a pilot error,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-14 9:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810131546180.19665@iabervon.org>
Hi,
On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> On Mon, 13 Oct 2008, Johannes Schindelin wrote:
>
> > I actually understand now why the tests started failing: the change from
> > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > get_branch() does not check if the branch has an initial commit.
> >
> > I am actually regretting making this change. Daniel, do you agree
> > that it might be better to change back to resolve_ref(), so that the
> > initial complaint (IIRC Han-Wen git pull'ed into a freshly initialized
> > repository with that utterly bogus "git pull origin master:master"
> > line) is not re-raised?
>
> Is it, in fact, okay to fetch into the current branch if it's "yet to be
> born"? I feel like it shouldn't be, since you'll get exactly the same
> problem that you would if the branch already existed: the index reflects
> the previous state (in this case, it's empty), so git will show that
> you've staged removing all of the files, right? So this would make the
> check for --update-head-ok more strict than before, but I think the
> behavior change is correct.
I think
http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
is the best link to see what Han-Wen said. Granted, it was a
misunderstanding on his part, but there have been quite a few people with
the same misunderstanding.
So what they did was
$ mkdir just-one-branch
$ cd just-one-branch
$ git init
$ git remote add origin <url>
$ git pull origin master:master
And this _will_ work correctly. Except when using get_branch(NULL)
instead of the validating resolve_ref().
When we talk about not breaking existing behavior, we have to talk about
this behavior, too.
So, my vote is to revert back to resolve_ref(), even if it needs more
lines.
Thoughts of others?
Ciao,
Dscho
^ permalink raw reply
* How many users of parsecvs are there?
From: Alex Bennee @ 2008-10-14 10:10 UTC (permalink / raw)
To: git; +Cc: keithp
I'm wondering how many people are there still using parsecvs to to
track a live CVS tree?
I've been using it for a while at work to track a rather monster CVS
repository. The main reasons are:
1. It's the fastest import I've come across so far. Given the size of
the CVS repo other solutions took far too long to do the conversion
2. It's simple to configure (if you can call "find" configuring),
assuming you have access to the CVS repo proper
3. It reliably regenerates the repository so you can run the entire
conversion from scratch the next day and hapily pull into working
repos (I assume if I got tother working they should exhibit this
property).
However I have come across a few problems. One of which involves files
not getting put into branches which I've managed hack a band-aid
solution for that involves ignoring date discrepancies. However having
mailed keith he made it clear he doesn't use it any more having
converted his stuff so it's currently not being actively maintained.
So the question really is are there people out there still using it?
If not I'll hang up my code exploring boots and have another go at
whatever is considered the best in class iterative CVS to GIT gateway.
If it's still a useful tool for other people as well I'm happy to
delve deeper into the code and seeing if any of the crinkles can be
ironed out.
It's interesting to note from the Git Users Survey 2008 that CVS is
still the second most used legacy version control system. One could
draw the conclusion that having a well supported bullet proof
incremental CVS import mechanism as part of git should still be a
fairly important goal. There are a lot (too many?) out of tree
solutions out there which makes approaching the task somewhat daunting
when first coming to git.
--
Alex, homepage: http://www.bennee.com/~alex/
^ permalink raw reply
* Re: [BUG?] git remote rm repo nukes local refs for mirror repo
From: Samuel Tardieu @ 2008-10-14 10:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810141131130.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Michael> I just noticed the hard way that "git remote rm repo" nukes
Michael> all local (mirrored) refs if repo had been setup with "git
Michael> remote add --mirror repo url". Some may argue that this
Michael> behaviour fits the description "deletes all remote tracking
Michael> branches" but I would claim it does not: mirrored branches
Michael> are not remote tracking branches in the proper sense.
Johannes> Count me into the former group. If you set up a "--mirror"
Johannes> repository, it defeats the purpose to mix that with _true_
Johannes> local branches.
IMO it should exit with an error and force to use "--force" to perform
the operation. The scenario I envision is a mirror becoming the
primary repository because the original source has disappeared. You
would want to remove the now-useless reference to the source, and
silently nuking all branches is wrong.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: concerns about git
From: Ciprian Dorin Craciun @ 2008-10-14 11:25 UTC (permalink / raw)
To: Brandon; +Cc: David Tweed, Shawn O. Pearce, deepwinter, git
In-Reply-To: <82c87da00810131251i52d10170h5c1991e2da0bd208@mail.gmail.com>
On Mon, Oct 13, 2008 at 10:51 PM, Brandon <siamesedream01@gmail.com> wrote:
> You can use "git config core.worktree <location>" to create a ".git"
> folder that manages a working copy in another location.
>
> I know some of the GUI tools don't support this though so I would only
> use it if truly necessary . (For example a using git to manage a
> mapped network drive, it would be faster to keep the ".git" folder on
> the local harddrive)
>
> More documentation here: http://www.kernel.org/pub/software/scm/git/docs/
>
> On Mon, Oct 13, 2008 at 2:40 PM, David Tweed <david.tweed@gmail.com> wrote:
>> On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>> # then every once in a while, or from a cron job
>>> $ git push --all backup
>>>
>>> Of course since Git is distributed you can you use this same approach
>>> to make backups to other systems. You can even edit the .git/config
>>> to give the [remote "backup"] section more than one url line, so
>>> that "git push --all backup" will send updated copies to multiple
>>> locations at once.
>>
>> Another advantage of 'git push'ing to another repository (possibly via
>> cron) as backup is that (for technical reasons) git push has to
>> 'parse' the new changes to your repository in order to push, so it is
>> likely to spot corruption (eg, dying disk) at that time and when you
>> can decide what to do about it. (I have enough backups all over the
>> place that I don't worry about not having a 'copy' of any stuff I care
>> about, but that there'll be some fatal corruption I don't notice
>> immediately that then gets propagated everywhere rendering them
>> useless.)
>>
>> --
>> cheers, dave tweed__________________________
>> david.tweed@gmail.com
I have the same problem as David, but I manage it by using a
symlink. That is my .git folder is a symlink to the real repository
(possibly on another partition). (So far I had no problems with this
setup.)
Ciprian Dorin Craciun.
^ permalink raw reply
* Re: [BUG?] git remote rm repo nukes local refs for mirror repo
From: Michael J Gruber @ 2008-10-14 11:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0810141131130.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 14.10.2008 11:32:
> Hi,
>
> On Tue, 14 Oct 2008, Michael J Gruber wrote:
>
>> I just noticed the hard way that "git remote rm repo" nukes all local
>> (mirrored) refs if repo had been setup with "git remote add --mirror
>> repo url".
>>
>> Some may argue that this behaviour fits the description "deletes all
>> remote tracking branches" but I would claim it does not: mirrored
>> branches are not remote tracking branches in the proper sense.
>
> Count me into the former group. If you set up a "--mirror" repository, it
> defeats the purpose to mix that with _true_ local branches.
>
> I'd color this a pilot error,
> Dscho
OK, I'll give some background about the motivation:
I have a "local" repo.
I want to create a "backup repo" which contains the same branches
(including proper remotes, svn remotes).
So, I create an empty bare repo somewhere (say store:backuprepo.git),
and in the local repo I do:
git remote add --mirror backup store:backuprepo.git
git push backup
I need "mirror=true" because otherwise branches are not created
automatically (on push) on the remote side. I need the '+refs/*:refs/*'
refspec because otherwise not all refs are mirrored. But now I can't use
"git remote rm backup" to remove the configuration because that would
take away all my local branches, too.
Instead, I could set up things with
git remote add backup store:backuprepo.git
git config remote.backup.push '+refs/*:refs/*'
Then all branches are mirrored on the remote automatically. But
interesting things happen after fetch and push... Read "recursion". So,
in order to avoid any remote/backup/foo branches on the local side I
would have to use
git remote add backup store:backuprepo.git
git config remote.backup.push '+refs/*:refs/*'
git config --unset remote.backup.fetch
in order to create a "backup remote" configuration. Maybe I'm just being
dense (which is actually OK for a functional analyst); I'd be happy
about any more direct solution. At least I think there should be one, a
backup bare remote mirror is a common use case, and the config massaging
above is not something to recommend to novice users.
Michael
P.S.: Yeah I know, git's no backup tool, there's rsync... ;)
^ permalink raw reply
* [PATCH] git-gui: Do not munge conflict marker lines in a normal diff
From: Johannes Sixt @ 2008-10-14 11:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
Previously, conflict markers were highlighted in two ways: (1) They
received a distinguishing color; and (2) they had the '+' removed at the
beginning of the line. However, by doing (2), a hunk that contained
conflict markers could not be staged or unstaged because the resulting
patch was corrupted. With this change we no longer modify the diff text
of a 2-way diff, so that "Stage Hunk" and friends work.
Note that 3-way diff of a conflicted file is unaffected by this change,
and '++' before conflict markers is still removed. But this has no negative
impact because in this mode staging hunks or lines is disabled anyway.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
lib/diff.tcl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index bdcbbf8..94ee38c 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -377,7 +377,6 @@ proc read_diff {fd cont_info} {
{+} {
if {[regexp {^\+([<>]{7} |={7})} $line _g op]} {
set is_conflict_diff 1
- set line [string replace $line 0 0 { }]
set tags d$op
} else {
set tags d_+
--
1.6.0.2.1493.g2969e
^ permalink raw reply related
* Rerunning merge on a single file
From: Kristian Amlie @ 2008-10-14 12:13 UTC (permalink / raw)
To: git
Hey, I have question about advanced merging.
Suppose I have a huge merge with conflicts all over the place. There is
no way to avoid them, so I start working from the top. At some point,
however, I make a mistake and lose the merge information for one file
(for example by checking out the file from HEAD).
In that case I would like to get the conflict markers back, and do that
file over again, but I don't want to throw away the rest of the index
state. Currently the only way I can see to do this is by checking out
several file versions under different names and then using git
merge-file on them.
Is there a better way to achieve this?
Kristian
^ permalink raw reply
* Re: Rerunning merge on a single file
From: Santi Béjar @ 2008-10-14 12:21 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <48F48CDB.1010309@trolltech.com>
On Tue, Oct 14, 2008 at 2:13 PM, Kristian Amlie
<kristian.amlie@trolltech.com> wrote:
> Hey, I have question about advanced merging.
>
> Suppose I have a huge merge with conflicts all over the place. There is no
> way to avoid them, so I start working from the top. At some point, however,
> I make a mistake and lose the merge information for one file (for example by
> checking out the file from HEAD).
>
> In that case I would like to get the conflict markers back, and do that file
> over again, but I don't want to throw away the rest of the index state.
> Currently the only way I can see to do this is by checking out several file
> versions under different names and then using git merge-file on them.
>
> Is there a better way to achieve this?
If the different versions are still in the index you could use:
$ git checkout --merge $file
Santi
^ permalink raw reply
* Re: Rerunning merge on a single file
From: Santi Béjar @ 2008-10-14 12:28 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <adf1fd3d0810140521g7f43ee3bs5d4e60772bcc1d8c@mail.gmail.com>
On Tue, Oct 14, 2008 at 2:21 PM, Santi Béjar <santi@agolina.net> wrote:
> On Tue, Oct 14, 2008 at 2:13 PM, Kristian Amlie
> <kristian.amlie@trolltech.com> wrote:
>> Hey, I have question about advanced merging.
>>
>> Suppose I have a huge merge with conflicts all over the place. There is no
>> way to avoid them, so I start working from the top. At some point, however,
>> I make a mistake and lose the merge information for one file (for example by
>> checking out the file from HEAD).
>>
>> In that case I would like to get the conflict markers back, and do that file
>> over again, but I don't want to throw away the rest of the index state.
>> Currently the only way I can see to do this is by checking out several file
>> versions under different names and then using git merge-file on them.
>>
>> Is there a better way to achieve this?
>
> If the different versions are still in the index you could use:
>
> $ git checkout --merge $file
Note that this is very new, as it was introduced in
v1.6.0.1-26-geac5a40, so you'll need at least 1.6.0.2.
Santi
^ permalink raw reply
* Re: Rerunning merge on a single file
From: Kristian Amlie @ 2008-10-14 12:48 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0810140521g7f43ee3bs5d4e60772bcc1d8c@mail.gmail.com>
Santi Béjar wrote:
> On Tue, Oct 14, 2008 at 2:13 PM, Kristian Amlie
> <kristian.amlie@trolltech.com> wrote:
>> Hey, I have question about advanced merging.
>>
>> Suppose I have a huge merge with conflicts all over the place. There is no
>> way to avoid them, so I start working from the top. At some point, however,
>> I make a mistake and lose the merge information for one file (for example by
>> checking out the file from HEAD).
>>
>> In that case I would like to get the conflict markers back, and do that file
>> over again, but I don't want to throw away the rest of the index state.
>> Currently the only way I can see to do this is by checking out several file
>> versions under different names and then using git merge-file on them.
>>
>> Is there a better way to achieve this?
>
> If the different versions are still in the index you could use:
>
> $ git checkout --merge $file
In my case the files were added to the index already, so I guess it
doesn't work then?
Kristian
^ permalink raw reply
* EGIT compare editor
From: Chris Dumoulin @ 2008-10-14 14:18 UTC (permalink / raw)
To: git
I seem to have successfully installed EGIT in Eclipse 3.4.1, but I can't
figure out how to bring up the compare editor to view diffs.
The EGIT plugin seems to be loaded and working for my project; I see
"[Git @ master]" beside the project name, and ">" beside changed files.
Also, the quickdiff seems to be working; I see a different colour in the
left margin beside changes within the file. The "Team" context menu
seems to be populated properly: "Commit", "Update Index (Refresh)",
"Show in Resource History", "Assume unchanged", "Track (Add)", "Untrack
(Remove)", "Apply Patch...", and below the separator "Show Local History".
I expect that after right-clicking on a changed file, I would have some
option under "Compare With" or "Team" that would allow me to diff the
current file against the HEAD or some other revision using the compare
editor, but I can't seem to find any way to do this. How do I bring up
the compare editor to view diffs?
Thanks,
Chris
^ permalink raw reply
* [PATCH] Add Linux PPC support to the pre-auto-gc example hook
From: Miklos Vajna @ 2008-10-14 14:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
contrib/hooks/pre-auto-gc-battery | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery
index b0a8caa..1f914c9 100644
--- a/contrib/hooks/pre-auto-gc-battery
+++ b/contrib/hooks/pre-auto-gc-battery
@@ -30,6 +30,9 @@ then
elif grep -q '0x01$' /proc/apm 2>/dev/null
then
exit 0
+elif grep -q "AC Power \+: 1" /proc/pmu/info 2>/dev/null
+then
+ exit 0
elif test -x /usr/bin/pmset && /usr/bin/pmset -g batt |
grep -q "Currently drawing from 'AC Power'"
then
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Shawn O. Pearce @ 2008-10-14 15:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810141145491.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 13 Oct 2008, Daniel Barkalow wrote:
>
> > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> >
> > > I actually understand now why the tests started failing: the change from
> > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > get_branch() does not check if the branch has an initial commit.
>
> So, my vote is to revert back to resolve_ref(), even if it needs more
> lines.
Yes, I agree, resolve_ref() is the best thing to be using here,
even if it is more code. get_branch() validates the commit and we
don't want that. We really just want to know if the current branch
is going to be updated, we don't care to what/why.
--
Shawn.
^ permalink raw reply
* retrieving a diff from git
From: Folkert van Heusden @ 2008-10-14 14:51 UTC (permalink / raw)
To: git
Hi,
How would I retrieve the 'kmemcheck' patches from git for the 2.6.27
kernel? I browsed to the url
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fx86%2Flinux-2.6-tip.git&a=search&h=HEAD&st=commit&s=kmemcheck
but could not find how to retrieve that diff.
Folkert van Heusden
--
Ever wonder what is out there? Any alien races? Then please support
the seti@home project: setiathome.ssl.berkeley.edu
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: EGIT compare editor
From: Shawn O. Pearce @ 2008-10-14 15:05 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: git
In-Reply-To: <48F4AA33.40605@oanda.com>
Chris Dumoulin <dumoulin@oanda.com> wrote:
> I seem to have successfully installed EGIT in Eclipse 3.4.1, but I can't
> figure out how to bring up the compare editor to view diffs.
>
> I expect that after right-clicking on a changed file, I would have some
> option under "Compare With" or "Team" that would allow me to diff the
> current file against the HEAD or some other revision using the compare
> editor, but I can't seem to find any way to do this. How do I bring up
> the compare editor to view diffs?
Robin knows the Eclipse integration better than I, but we may be
missing the feature to compare the working directory revision to
the last committed revision (or the index revision).
I'm pretty sure the compare editor is available in the History view
(Team -> Show resource in History) by double clicking the file
path when a commit node is selected. But that's obviously only
historical diffs.
--
Shawn.
^ 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