* Re: "warning: no common commits" triggered due to change of remote's IP address?
From: Brent Goodrick @ 2009-03-01 23:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200903012221.03662.trast@student.ethz.ch>
On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> However, your use of + refspecs in
>
>> gitw fetch 88.99.100.101:git.repos/environ.git
>> +refs/heads/home:refs/remotes/origin/home
>
> makes me wonder: have you rewritten the repo hosting 'home' between
> two fetches? Using (especially, but not only) git-filter-branch can
> easily render your history disjoint from the pre-filtering state.
>
>> warning: no common commits
>
> Either your history is very short and really has no common commits
> whatsoever, or it gave up because of the 256 revision limit during
> find_common().
Hmmm, maybe, without knowing it. Originally, that section of the
.git/config file had "*"'s where "home" was. To clarify, the original
was:
[remote "origin"]
url = <some_ip_address>:git.repos/environ.git
fetch = +refs/heads/*:refs/remotes/origin/*
and the current one is now:
[remote "origin"]
url = <some_ip_address>:git.repos/environ.git
fetch = +refs/heads/home:refs/remotes/origin/home
Maybe I had made that change and this is the first time I am doing a
fetch to using that change. I thinking that was the cause of this,
because I retried doing a fetch into a separate throw-away repo with
just the change of IP address, and it did not need to fetch anything
more. I had not executed git-filter-branch at all.
>> 1. Will terminating the git fetch like I did leave the satellite repo
>> in an inconsistent state? If so, is my only choice to start
>> a new repo from scratch on the satellite machine, or is there some
>> repair mechanism?
>
> It will just leave a temporary pack file that git-gc will eventually
> remove. You can just try another fetch later.
Good, that is what I would have expected.
Brent
^ permalink raw reply
* [RFC] Refspec patterns with * in the middle
From: Daniel Barkalow @ 2009-03-01 23:42 UTC (permalink / raw)
To: git
I've got an annoying repository where all of the branches upstream[*] have
names, for a project "my-proj" like:
some/constant/stuff/$VERSION/junk/my-proj
I'd like to be able to use refspecs like:
fetch = some/constant/stuff/*/junk/my-proj:refs/remotes/origin/*
I've written an implementation (which mainly involved having only one
place do the matching and replacement for pattern refspecs, and then
making that one place a little more clever), so that's not hard. But we
currently prohibit refspecs like this, and I think we may want to prohibit
some patterns of this general form, in order to keep typos from doing
surprising things.
My use case is actually, more precisely:
some/constant/stuff/$PROJ-$NUMBER/junk/my-proj
Where $NUMBER is the version number, and $PROJ is usually, but not quite
always "my-proj"; the exception being that it might be effectively a
superproject. So I'd like to have:
fetch = some/constant/stuff/my-proj-*/junk/my-proj:refs/remotes/origin/*
But I can live with remote branches like "my-proj-2.4" instead of "2.4".
I think it would make sense, and limit typo damage, to say that the * can
only expand to something with a '/' in it if the star has a slash or the
end of the string on each side.
What are other people's thoughts? Should I have a config option for how
flexible matching is permitted? Any particular constraints I should have
in general?
[*]
(This is actually a Perforce upstream, but I want to keep the mapping from
Perforce into git simple and not grow another pattern-matching format, so
I'm just copying Perforce paths as ref names, and then I want the match
them with the usual code)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* merge, keeping the remote as a new file?
From: Caleb Cushing @ 2009-03-02 0:16 UTC (permalink / raw)
To: git
I have an unmerged file... the resolution I'd like to have is
checkout the local one for the current file name. take the remote
version and give it a new file name. what's the best way to do that?
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: fatal: git write-tree failed to write a tree
From: Caleb Cushing @ 2009-03-02 0:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903012210230.10279@pacific.mpi-cbg.de>
On Sun, Mar 1, 2009 at 4:10 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> A tree cannot contain unmerged files.
>
I didn't do that, git did. I've tried running git reset --hard HEAD
(and git status shows a clean tree before hand).
so how can I resolve it?
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Applying the changes of a specific commit from one branch to another.
From: NewToGit @ 2009-03-02 1:44 UTC (permalink / raw)
To: git
Applying the changes of a specific commit from one branch to another.
Scenario:
- branched off master and created story123 branch.
- made three separate change commits to story123:
- 'fixed bug123'
- 'fixed bug456'
- 'fixed bug789'
- now I realized that I need to apply only one commit 'fixed bug789' to
master
Question: What's the best way to go about doing this?
Thanks for the help!
NewToGit
--
View this message in context: http://www.nabble.com/Applying-the-changes-of-a-specific-commit-from-one-branch-to-another.-tp22280717p22280717.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Applying the changes of a specific commit from one branch to another.
From: Chris Packham @ 2009-03-02 1:58 UTC (permalink / raw)
To: NewToGit; +Cc: git
In-Reply-To: <22280717.post@talk.nabble.com>
On Mon, Mar 2, 2009 at 2:44 PM, NewToGit <omarnetbox@gmail.com> wrote:
> Scenario:
>
> - branched off master and created story123 branch.
> - made three separate change commits to story123:
> - 'fixed bug123'
> - 'fixed bug456'
> - 'fixed bug789'
>
> - now I realized that I need to apply only one commit 'fixed bug789' to
> master
>
> Question: What's the best way to go about doing this?
>
What you want to do is "cherry-pick" the commit 'fixed bug789'. With
git there are several ways to do this but the one I'd use is the
cherry-pick functionality of gitk.
git checkout master
gitk --all
<right click on the 'fixed bug789' commit and select "cherry-pick this commit">
Like I say there are plenty of ways to do something like this. I'm
sure you'll get plenty more responses.
^ permalink raw reply
* Re: Applying the changes of a specific commit from one branch to another.
From: Chris Packham @ 2009-03-02 2:52 UTC (permalink / raw)
To: omar-uk; +Cc: git
In-Reply-To: <22d8f6460903011824t18c01d83p16c05af9f9a12ee5@mail.gmail.com>
On Mon, Mar 2, 2009 at 3:24 PM, omar-uk <omarnetbox@googlemail.com> wrote:
> Many Thanks Chris! for the quick response.
>
> What I do right click on? I tried the commit message but not getting
> any menus or anything. BTW I'm using a mac not sure if it makes a
> difference.
Hmm, Doesn't mac imply only one mouse button? Anyway whatever the
equivalent to right click is you click on the headline (also referred
to as the subject) in the tree (top half of the gitk window).
Also for mac a lot of people are using GitX which has similar
functionality to gitk (I can't claim any knowledge about it).
^ permalink raw reply
* Re: merge, keeping the remote as a new file?
From: Jeff King @ 2009-03-02 4:11 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0903011616w32ebdad9ofc096f5d1fd3174a@mail.gmail.com>
On Sun, Mar 01, 2009 at 07:16:10PM -0500, Caleb Cushing wrote:
> I have an unmerged file... the resolution I'd like to have is
> checkout the local one for the current file name. take the remote
> version and give it a new file name. what's the best way to do that?
I would use:
$ git show :2:file >file
$ git show :3:file >newfile
$ git add file newfile
You can do the first with "git checkout --ours", but I don't think there
is a way with "checkout" to say "checkout this path, but put it in a
different place".
-Peff
^ permalink raw reply
* Re: merge, keeping the remote as a new file?
From: Charles Bailey @ 2009-03-02 6:36 UTC (permalink / raw)
To: Jeff King; +Cc: Caleb Cushing, git
In-Reply-To: <20090302041113.GA3094@coredump.intra.peff.net>
On Sun, Mar 01, 2009 at 11:11:13PM -0500, Jeff King wrote:
> On Sun, Mar 01, 2009 at 07:16:10PM -0500, Caleb Cushing wrote:
>
> > I have an unmerged file... the resolution I'd like to have is
> > checkout the local one for the current file name. take the remote
> > version and give it a new file name. what's the best way to do that?
>
> I would use:
>
> $ git show :2:file >file
> $ git show :3:file >newfile
> $ git add file newfile
>
> You can do the first with "git checkout --ours", but I don't think there
> is a way with "checkout" to say "checkout this path, but put it in a
> different place".
>
> -Peff
You can use git checkout-index --temp --stage=3 and then move it from
the auto-generated temporary name into its new place.
The shell function checkout_staged_file in git-mergetool.sh does this
programmatically, it's not very beautiful as the output of
checkout-index --temp requires a bit of expr magic to get the
temporary file name out.
Using a checkout variant instead of a show or a cat-file might be
important if you are doing autocrlf or some other smudging.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: merge, keeping the remote as a new file?
From: Jeff King @ 2009-03-02 6:45 UTC (permalink / raw)
To: Charles Bailey; +Cc: Caleb Cushing, git
In-Reply-To: <20090302063604.GA17245@hashpling.org>
On Mon, Mar 02, 2009 at 06:36:04AM +0000, Charles Bailey wrote:
> You can use git checkout-index --temp --stage=3 and then move it from
> the auto-generated temporary name into its new place.
Hmm. I was hoping there was something that would use the name "--theirs"
instead of the mysterious "stage level 3". But it's still nicer than the
"git show" I gave because of:
> Using a checkout variant instead of a show or a cat-file might be
> important if you are doing autocrlf or some other smudging.
Right. For some reason I was thinking that cat-file did not handle this
but "git show" did, but I just tested and it clearly doesn't. So yes,
you should definitely use checkout-index if you care about conversions.
-Peff
^ permalink raw reply
* Re: merge, keeping the remote as a new file?
From: Björn Steinbrink @ 2009-03-02 6:59 UTC (permalink / raw)
To: Jeff King; +Cc: Charles Bailey, Caleb Cushing, git
In-Reply-To: <20090302064519.GA5635@coredump.intra.peff.net>
On 2009.03.02 01:45:19 -0500, Jeff King wrote:
> On Mon, Mar 02, 2009 at 06:36:04AM +0000, Charles Bailey wrote:
>
> > You can use git checkout-index --temp --stage=3 and then move it from
> > the auto-generated temporary name into its new place.
>
> Hmm. I was hoping there was something that would use the name "--theirs"
> instead of the mysterious "stage level 3". But it's still nicer than the
> "git show" I gave because of:
>
> > Using a checkout variant instead of a show or a cat-file might be
> > important if you are doing autocrlf or some other smudging.
>
> Right. For some reason I was thinking that cat-file did not handle this
> but "git show" did, but I just tested and it clearly doesn't. So yes,
> you should definitely use checkout-index if you care about conversions.
Hm, how about this?
git checkout --theirs file
git mv file newname
git checkout HEAD file # Can't use --ours here due to the mv
Should work with the CRLF stuff, uses no plumbing, no stage numbers,
there's no messing with random temp file names and it's still just three
commands.
Björn
^ permalink raw reply
* Re: merge, keeping the remote as a new file?
From: Jeff King @ 2009-03-02 7:04 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Charles Bailey, Caleb Cushing, git
In-Reply-To: <20090302065949.GD6289@atjola.homenet>
On Mon, Mar 02, 2009 at 07:59:49AM +0100, Björn Steinbrink wrote:
> Hm, how about this?
> git checkout --theirs file
> git mv file newname
> git checkout HEAD file # Can't use --ours here due to the mv
Actually, you can use --ours if you don't "git mv":
git checkout --theirs file
mv file newfile
git checkout --ours file
git add file newfile
One more command, but I think more obvious about what is going on (and I
think both are better than the other suggestions).
-Peff
^ permalink raw reply
* Re: [PATCH v2] send-email: add --confirm option
From: Junio C Hamano @ 2009-03-02 7:34 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Nanako Shiraishi, Paul Gortmaker
In-Reply-To: <1235924234-16923-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> send-email violates the principle of least surprise by automatically
> cc'ing additional recipients without confirming this with the user.
>
> This patch teaches send-email a --confirm option. It takes the
> following values:
>
> --confirm=always always confirm before sending
> --confirm=never never confirm before sending
> --confirm=cc confirm before sending when send-email has
> automatically added addresses from the patch to
> the Cc list
> --confirm=compose confirm before sending the first message when
> using --compose. (Needed to maintain backwards
> compatibility with existing behavior.)
> --confirm=auto 'cc' + 'compose'
>
> The option defaults to 'compose' if any suppress Cc related options have
> been used, otherwise it defaults to 'auto'.
>
> Unfortunately, it is impossible to introduce this patch such that it
> helps new users without potentially upsetting some existing users. We
> attempt to mitigate the latter by:
>
> * Allowing the user to "git config sendemail.config never"
> * Allowing the user to say "all" after the first prompt to not be
> prompted on remaining emails during the same invocation.
> * Telling the user about the "sendemail.confirm" setting whenever they
> use "all"
> * Only prompting if no --suppress related options have been passed, as
> using such an option is likely to indicate an experienced send-email
> user.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Other than that the "sendemail.config never" is probably a typo, I think
this is the best you (or anybody) could do at this moment, unless we take
the route to introduce an "improved and different command", which I
actually am slightly in favor.
In any case, with the lesson I learned from the post v1.6.0 fiasco, it
might make sense to make the command louder when it needs to look at the
setting of $confirm option and when the user does not have anything in the
config nor command line.
What I mean is this.
In this codepath,
> + $needs_confirm = (
> + $confirm eq "always" or
> + ($confirm =~ /^(?:auto|cc)$/ && @cc) or
> + ($confirm =~ /^(?:auto|compose)$/ && $compose && $message_num == 1));
> +
if @cc is not empty, or $compose is true, you _need to know_ what the user
wants to happen, and you need to look at $confirm to decide (otherwise the
value of $confirm does not matter). In such a case, if the repository is
unconfigured with a sendemail.confirm configuration and the there was no
explicit --confirm from the command line, you do not know what the user
wants. Instead of silently assuming 'auto' to confirm and potentially
annoying the users with this new extra step, the command could also say
"by the way, if you do not want to see this message, you can squelch it by
'git config sendemail.confirm never'" when it defaults to 'auto'.
The command could also refuse to work in such a case and instead explain
what the user's choices are, and instruct "say 'git config
sendemail.confirm auto' if you are not sure" or something like that, but I
think for this particular new option it is a bit overkill and I wouldn't
suggest going that far.
^ permalink raw reply
* Re: [PATCH 2/2 RFC] fetch-pack: log(n)-transmission find_common()
From: Junio C Hamano @ 2009-03-02 7:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: Brent Goodrick, git
In-Reply-To: <200903012237.40891.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> But it also turns out, as you can see, that git-send-email happily
> ignores --in-reply-to if threading is disabled. :-(
Yeah, I think I noticed it recently, too. Thanks for a quick fix.
^ permalink raw reply
* Problem in pushing git
From: Lahiru Perera @ 2009-03-02 7:31 UTC (permalink / raw)
To: git
Hi Im Lahiru im very new to git...Im using linux mint and i have problem
using git...
1. I have a server and i create a new repo on it..buy this command
#mkdir test.git
#cd test.git
#vi lahiru "add a line in it"
# git add .
# git commit -m"first git"
2. And i went to a client and i clone the project..
#git clone ssh://user@mydomain.com
#cd test
#edit file"lahiru"
#vi poojitha "add a line to poojitha"
#git add .
#git commit -m"add a line on lahiru"
#git push origin master
all these i showed to u is the way i have created, clone and push the
repo's.. my problem is when i finishing the pushing part the changer's
are not save on the main repo means on the server if i typed it showed
is as delete line...."git status"
y is this not saving?
git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lahiru
# deleted: poojitha
Im finding a solution from last few month
Thks
Lahiru.
--
Lahiru Perera
System Administrator
Providence Network & Solutions (Pvt) Ltd.
No. 752/1, Dr.Danister De Silva Mawatha,
Colombo 09,
Sri Lanka.
Phones (work) = +94 11 2698232, +94 11 5749575
Fax = +94 11 2698232
E-mail = lahiru@providencesl.com
Web Page = www.providencesl.com
Skype = lahirucom
google = lahirucom
yahoo = malinban
^ permalink raw reply
* Re: [PATCH] git.el: Only show completions from refs/heads
From: David Kågedal @ 2009-03-02 7:45 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87prh1tc5y.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Signed-off-by: David Kågedal <davidk@lysator.liu.se>
>> ---
>>
>> Here is a version that can to both commit name lookup and branch name
>> lookup, and with a configuration parameter that determines how to find
>> branch names to complete on.
>
> Why do you introduce a separate function for checkouts? I don't see
> much need to have a different set of completions for checkout
> vs. cherry-pick, they both can be used with an arbitrary commit anyway.
Yes, but the typical uses differ a lot. The (overwhelmingly) typical
use of checkout is to switch to another branch. The typical use of
cherry-pick is to pick any commit and not treat branch heads
specially.
So when switching branches, I obviously want a simple way to select
which branch to switch to. When cherry-picking, I would need some
simple way of picking any single commit, but that's hard so making it
easy to pick any named commit is probably the reasonable solution.
--
David Kågedal
^ permalink raw reply
* Re: Yesss! sourceforge.net and Git
From: Miles Bader @ 2009-03-02 7:50 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, git
In-Reply-To: <fabb9a1e0903011411s3a589fdby5c354c97433ec402@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> Well, you work in the shop. Lots of politics, my son, lots of politics.
>
> Yeah, it was mostly wishful thinking from my side. There's some work
> being done on git and hg interoperability though, so if worst comes to
> worst, I could live with using something like git-hg ;).
Is code.google.com really that bad...?
I always thought google was supposed to be a bit better than the other
guys...
-Miles
--
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem. -- Numerical methods in C,
Chapter 9. "Root Finding and Nonlinear Sets of Equations"
^ permalink raw reply
* Re: Problem in pushing git
From: Sverre Rabbelier @ 2009-03-02 7:51 UTC (permalink / raw)
To: Lahiru Perera; +Cc: git
In-Reply-To: <49AB8B4F.90006@providencesl.com>
Heya,
On Mon, Mar 2, 2009 at 08:31, Lahiru Perera <lahiru@providencesl.com> wrote:
> Im finding a solution from last few month
I'm glad to hear that you've been trying to find the solution
yourself, but why did you not look at the faq [0]? The exact same
question you asked has been answered there (see [0]).
[0] http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Yesss! sourceforge.net and Git
From: Sverre Rabbelier @ 2009-03-02 7:53 UTC (permalink / raw)
To: Miles Bader; +Cc: Johannes Schindelin, git
In-Reply-To: <buoab84xt17.fsf@dhlpc061.dev.necel.com>
Heya,
On Mon, Mar 2, 2009 at 08:50, Miles Bader <miles@gnu.org> wrote:
> Is code.google.com really that bad...?
It is currently, since they only host svn ;).
> I always thought google was supposed to be a bit better than the other
> guys...
Who knows, at the moment though, they only have svn and I'm personally
not holding my breath for git support anytime soon.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/3] t3400-rebase: Move detached HEAD check earlier
From: Junio C Hamano @ 2009-03-02 8:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1235902803-32528-1-git-send-email-j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Long story: The test that preceded the one in question tests that a
> rebased commit degrades from a content change with mode change to a
> mere mode change. But on Windows, where we have core.filemode=false,
> the original commit did not record the mode change, and so the rebase
> operation did not rebase anything. This caused the subsequent detached
> HEAD test to fail.
Thanks.
I'll apply it as is since it is very close to the real release, but I
think a more suitable fix would be to make tests less dependent on the
outcome of earlier tests.
^ permalink raw reply
* Re: Yesss! sourceforge.net and Git
From: Felipe Contreras @ 2009-03-02 8:06 UTC (permalink / raw)
To: Miles Bader; +Cc: Sverre Rabbelier, Johannes Schindelin, git
In-Reply-To: <buoab84xt17.fsf@dhlpc061.dev.necel.com>
On Mon, Mar 2, 2009 at 9:50 AM, Miles Bader <miles@gnu.org> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>>> Well, you work in the shop. Lots of politics, my son, lots of politics.
>>
>> Yeah, it was mostly wishful thinking from my side. There's some work
>> being done on git and hg interoperability though, so if worst comes to
>> worst, I could live with using something like git-hg ;).
>
> Is code.google.com really that bad...?
I think it's almost perfect... except for the choice of VCS.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v2] send-email: add --confirm option
From: Nanako Shiraishi @ 2009-03-02 8:24 UTC (permalink / raw)
To: Jay Soffian; +Cc: Paul Gortmaker, git, Junio C Hamano
In-Reply-To: <76718490903010949h7b64eb97ob567101fbc7e4cd1@mail.gmail.com>
Quoting Jay Soffian <jaysoffian@gmail.com>:
> (Please correct me if my summary is wrong, but that's how I recall it.)
I think your summary has some things right.
- Many people complained git-foo being on their paths in the past;
- Version 1.6.0 removed git-foo from users' path; and
- Many people didn't like the change after the fact.
However, you are completely wrong about the escape hatch.
If your judgement on how seriously you need to treat the backward compatibility is based on your understanding of the issue you summarized in your message, you need to reconsider what you are proposing, after learning from the true history.
The transition plan was first announced officially as part of the
release notes for version 1.5.4. It said three things:
- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Notice that:
- "now" is December 1st, 2007.
- "will be removed in the future" happened on August 17th, 2008 at version 1.6.0.
- The notice EXPLICITLY promises to keep supporting the use of git-foo if you prepend output of 'git --exec-path'.
In other words, there was an escape hatch that had been very carefully in preparation for nine months. The same escape hach, and the promise to keep supporting it, was repeated in the release notes for version 1.6.0.
You can refresh your memory (or read it for the first time, if you weren't around back then) with a message from Junio on August 24th, 2008 after version 1.6.0 was released:
http://thread.gmane.org/gmane.comp.version-control.git/93511
It summarized "the original plan" (read the message and find the phrase in the middle) and outlined how it should be implemented if the git community still wanted to go through with the plan.
With the discussion that followed the message, the community decided not to do anything (also known as the "alternative A").
The escape hatch was there from the beginning, is still there, and it will remain there. I should also add that it was Junio's veto of Linus'es proposal to stop installing git-foo commands for builtins that enabled this escape hatch.
http://thread.gmane.org/gmane.comp.version-control.git/51245/focus=51272
By the way, I don't think the lesson you should take home is the need for an escape hatch. Read the message by Junio on August 24th, 2008. Being nice and not too loud during the deprecation period kept users complacent about upcoming changes and upset them when the change finally came. Being un-nice and too loud during the deprecation period would have upset them early instead. You cannot avoid upsetting users either way whenever you change the behavior. That's the lesson you should learn.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: proper way to merge?
From: Bryan Donlan @ 2009-03-02 8:33 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E709F06FDA@EXCHANGE.trad.tradestation.com>
On Fri, Feb 27, 2009 at 5:11 PM, John Dlugosz <JDlugosz@tradestation.com> wrote:
> I'm merging two branches: let's say "dev" is for development of future
> releases, and "rel" is changes made to the current release for immediate
> application. Now I want to bring the changes made in rel back to dev.
>
> Rather than trying to merge it all at once, I'm applying the changes a
> few at a time and making sure it still compiles as I go. Then,
> git-reset and I have dev as my HEAD and the desired merge result in the
> working tree.
>
> Now, I want to introduce the proper commit node to show that this is the
> graft. But, I don't want to be presented with all the differences that
> I already resolved; I know what it should look like already. How do I
> commit the current state of things and have it show up with both dev and
> rel as parents? (then make that the new dev)
>
> I'm also interesting in learning how to do it better next time. But I'm
> doing the incremental merging now and need to know how to conclude it.
So, if I understand correctly, you've manually applied (manually
applying diffs or something?) your changes from the release branch to
the dev branch, and now want to inform git of what happened?
If so, you could commit what you have now, use a graft to change its
parentage, then git-filter-branch to actually update the commit
object. Something like this, I believe:
git commit -m 'Merge .....'
echo '<full 40-character commit ID of the merge> <parent on the dev
branch> <parent on the release branch>' >> .git/info/grafts
git-filter-branch dev~..dev
## You can remove (that line from) .git/info/grafts now
In the future, you may want to perform this sort of incremental merge
by simply git merging intermediate revisions in the release branch.
^ permalink raw reply
* Re: "warning: no common commits" triggered due to change of remote's IP address?
From: Thomas Rast @ 2009-03-02 8:40 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <e38bce640903011501t2c7a134dp887f5a96db3db0f4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]
Brent Goodrick wrote:
> On Sun, Mar 1, 2009 at 1:20 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> > [...] have you rewritten the repo hosting 'home' between
> > two fetches? Using (especially, but not only) git-filter-branch can
> > easily render your history disjoint from the pre-filtering state.
>
> Hmmm, maybe, without knowing it.
It's rather hard to rewrite history without knowing it, there are big
warnings all over the relevant tools' manpages...
> Originally, that section of the
> .git/config file had "*"'s where "home" was. To clarify, the original
> was:
>
> [remote "origin"]
> url = <some_ip_address>:git.repos/environ.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> and the current one is now:
>
> [remote "origin"]
> url = <some_ip_address>:git.repos/environ.git
> fetch = +refs/heads/home:refs/remotes/origin/home
>
> Maybe I had made that change and this is the first time I am doing a
> fetch to using that change. I thinking that was the cause of this,
> because I retried doing a fetch into a separate throw-away repo with
> just the change of IP address, and it did not need to fetch anything
> more. I had not executed git-filter-branch at all.
Ironically I cannot reproduce this except with my "own" version that
includes the patch I posted yesterday. I'll have to look into why it
fails to list any refs to the remote. In the meantime please
disregard that patch.
If you still have a repo that can reproduce the problem, please keep a
copy for future investigation, and then try
git fetch-pack -v $url refs/remotes/origin/home 2>&1 \
| git name-rev --stdin
The -v will dump a lot of output about the common commit search. The
message "giving up" indicates that you hit the 256 commit limit; if
that doesn't appear, please include the full output so that we can see
where it stops.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: "warning: no common commits" triggered due to change of remote's IP address?
From: Thomas Rast @ 2009-03-02 8:56 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <200903020940.24813.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 434 bytes --]
Thomas Rast wrote:
> If you still have a repo that can reproduce the problem, please keep a
> copy for future investigation, and then try
>
> git fetch-pack -v $url refs/remotes/origin/home 2>&1 \
> | git name-rev --stdin
Actually this should name the remote's idea of the ref, i.e.,
git fetch-pack -v $url refs/heads/home 2>&1 \
| git name-rev --stdin
Sorry.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ 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