* Re: [PATCH] Clarify git-format-patch --in-reply-to
From: Nanako Shiraishi @ 2008-12-19 21:51 UTC (permalink / raw)
To: jidanni; +Cc: gitster, git
In-Reply-To: <87k59wc73n.fsf@jidanni.org>
Quoting jidanni@jidanni.org:
> Signed-off-by: jidanni <jidanni@jidanni.org>
I understand that "Signed-off-by" is about code ownership and thought that the official history prefers to have a real name instead of a pseudonym. Perhaps you would want to say "Dan Jacobson <jidanni@jidanni.org>" or something similar?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Odd merge behaviour involving reverts
From: Nanako Shiraishi @ 2008-12-19 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Alan, git
In-Reply-To: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> I hope this clears up confusion and fear.
You are correct that I misunderstood what Alan meant by corrected branch.
I think your explanation will help people if we make it part of the documentation. Especially because two different cases need two different recovery methods, and people need to learn which is which.
Thank you for your detailed response.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Git Notes idea.
From: Jeff King @ 2008-12-19 21:25 UTC (permalink / raw)
To: Govind Salinas; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <5d46db230812190938r4e8ff994gfcb616c750be0f22@mail.gmail.com>
On Fri, Dec 19, 2008 at 11:38:55AM -0600, Govind Salinas wrote:
> This is my concern with keeping a history of the notes pseudo-branch. Let
> me restate what you are saying with an example
>
> 1) on branch A commit a
> 2) add note a`
> 3) on branch B commit b
> 4) add note b`
> 5) on branch B commit c
> 6) add note c`
> 7) delete branch A
> 8) gc after a time such that a is pruned
>
> Now either I will always have a note a` as an object forever even though
> the only commit that points to it is gone or I have to re-write the history of
> the notes branch from the point that it was added.
Yes, that's correct.
> Given this problem, is it really such a good idea to keep the history?
I think so. Otherwise how will you push and pull notes? You won't even
know which one is the more recent tree, let alone handle any merges
caused by editing notes in two places.
> On the other, other hand, pushing and pulling notes if a history is kept
> will have to involve a lot of rebasing/merging.
Depending on your workflow. It might just involve a lot of fast forwards
if the note writer is in one place.
> A possible solution is that notes are per-branch,
>
> refs/notes/heads/master
> refs/notes/heads/foo/bar
> refs/notes/remotes/baz/bang
Sorry, I don't quite get it. You are asking for per-branch notes that
keep history, or per-branch notes that don't keep history?
If the former, then you haven't solved the cruft accumulation problem.
You can get obsolete notes in your note history by rebasing on a branch
that is long-running (which is OK as long as you haven't published
_those particular_ commits). Or are you proposing to rebase and cleanup
the notes history every time you do a destructive operation?
If the latter, then I don't see how you've solved the push-pull and
merge problem (which you need history for).
But in either case, I think the solution is non-intuitive. If I annotate
a commit, and then merge the commit from one branch to another,
shouldn't the annotation stay?
Really, I am not sure this is worth getting too concerned about. Since
we are talking about cruft in the _history_ of the notes branch, it
won't impact actual notes usage (which will always just deal with the
most recent tree). So really we are talking about some uninteresting
objects in the db, which wastes some space. In practice, I suspect this
won't be that large because notes themselves are going to be relatively
short and in many cases, repetitive (i.e., many annotations may have the
same blob hash for several commits). And if it is a space problem, then
the right solution is to periodically truncate the notes history by
rewriting.
-Peff
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Jeff King @ 2008-12-19 20:51 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, spearce, git
In-Reply-To: <87vdtfc389.fsf@jidanni.org>
On Sat, Dec 20, 2008 at 04:35:50AM +0800, jidanni@jidanni.org wrote:
> JK> - the object pack in the bundle is "thin", meaning it may contain
> JK> deltas against objects that are reachable from A, but not B. So even
> JK> _within_ a changed file, you may see only the changes from A to B.
>
> OK, we here at the police forensics department would be very happy if
> we could at least get some ASCII out of that .BDL file, even if it is
> just a diff shred,
> - The password to the time bomb was BLORFZ
> + The password to the time bomb is NORFLZ
> that would be fine. All we know is after the work PACK it is all
> binary, and git-unpack-objects and git-unpack-file don't work on it.
AFAIK, there is no tool to try salvaging strings from an incomplete pack
(and you can't just run "strings" because the deltas are zlib
compressed). So if I were in the police forensics department, I think I
would read Documentation/technical/pack-format.txt and start hacking a
solution as quickly as possible.
-Peff
^ permalink raw reply
* Re: jgit doesn't support "compare with" and "replace with"?
From: Robin Rosenberg @ 2008-12-19 20:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Martin_S, git
In-Reply-To: <20081219152045.GR32487@spearce.org>
fredag 19 december 2008 16:20:45 skrev Shawn O. Pearce:
> Martin_S <iksdrijf@yahoo.com> wrote:
> >
> > Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
> > list "compare with" and "replace with". Am I doing something wrong?
>
> We haven't implemented them in EGit. So its not surprising that
> they aren't appearing.
Actually, we had it in v0.3 though it didn't always work. In particular it didn't work on
Windows...
The history rewrited killed it, but re-adding it would not be to hard, It's mostly about passing two explicit
versions to compare, which is already done in
The old version disappeared in 07f04ae5b1771069667028d225196daff29402a0, checkout out and rebuild
if you are really desperate. Reverting it is an option, but that is not trivial either so going forward and
reimplementing it (correctly this time) is a more appealing approach. Dependig on your needs, i.e. if
you only don't need clone/fetch/push you could go back to the commit mentioned above. The closest
tagged version is v0.3.1. As a bonus it draws the graph correctly, though it is not optimal.
-- robin
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 20:35 UTC (permalink / raw)
To: peff; +Cc: mdl123, spearce, git
In-Reply-To: <20081219202118.GA26513@coredump.intra.peff.net>
JK> In particular, if a bundle contains changes between some commit A
JK> and some commit B, then:
JK> - files that were not changed between A and B will not be included at
JK> all
JK> - the object pack in the bundle is "thin", meaning it may contain
JK> deltas against objects that are reachable from A, but not B. So even
JK> _within_ a changed file, you may see only the changes from A to B.
OK, we here at the police forensics department would be very happy if
we could at least get some ASCII out of that .BDL file, even if it is
just a diff shred,
- The password to the time bomb was BLORFZ
+ The password to the time bomb is NORFLZ
that would be fine. All we know is after the work PACK it is all
binary, and git-unpack-objects and git-unpack-file don't work on it.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Jeff King @ 2008-12-19 20:21 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, spearce, git
In-Reply-To: <87zlirc49l.fsf@jidanni.org>
On Sat, Dec 20, 2008 at 04:13:26AM +0800, jidanni@jidanni.org wrote:
> There must be a way to make a "phony tree" or whatever to "attach to"
> so extraction can proceed. Be sure to spell it all out on the
> git-bundle man page as a reference in case some non-computer people
> need to do aforementioned emergency extraction one day.
No, that information may not even be in the bundle at all (unless it is
a bundle that has a 0-ref basis). In particular, if a bundle contains
changes between some commit A and some commit B, then:
- files that were not changed between A and B will not be included at
all
- the object pack in the bundle is "thin", meaning it may contain
deltas against objects that are reachable from A, but not B. So even
_within_ a changed file, you may see only the changes from A to B.
If the bundle has a 0-ref basis, then you can clone straight from the
bundle, which must have everything.
-Peff
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 20:13 UTC (permalink / raw)
To: mdl123; +Cc: spearce, git
In-Reply-To: <494BFCAF.9060703@verizon.net>
SOP> If the bundle requires 0 refs (like above) then you can init a
SOP> new repository and should be able to fetch from it:
SOP> git init
SOP> git pull bundle.bdl master
Phew, that worked. Thank you!
ML> With relatively recent git (not sure the version), you can just do
ML> git clone bundle.bdl
Not with git version 1.5.6.5, Debian sid.
Anyway, for man page completeness, I still see the day when:
SOP> You can't just "get the files out". A bundle contains deltas,
SOP> where you need the base in order to recreate the file content.
SOP> It can't be unpacked in a vacuum.
That is nice by we here at the forensics department of XYZ police
force just need to get the files out. We tried "PK UNZIP" but that
didn't extract them. We contacted the Computer Science Dept. but
that's who they're holding hostage.
SOP> To unpack a bundle you need to clone the project and then fetch
SOP> from it:
SOP> git clone src...
SOP> git pull bundle.bdl master
That is nice but the perpetrators have destroyed everything except for
that one bundle.bdl file, which contains the password to defuse the
time bomb.
There must be a way to make a "phony tree" or whatever to "attach to"
so extraction can proceed. Be sure to spell it all out on the
git-bundle man page as a reference in case some non-computer people
need to do aforementioned emergency extraction one day.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Junio C Hamano @ 2008-12-19 20:07 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, git
In-Reply-To: <87iqpgc6bn.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Someone has handed you a "git bundle".
> How do you get the files out of it?
> If it were cpio, you would use -i, if it were tar, you would use -x...
> You read the git-bundle man page.
> You only get as far as
> # git-bundle verify bundle.bdl
> The bundle contains 1 ref
> d01... /heads/master
> The bundle requires these 0 ref
> bundle.bdl is okay
>
> The rest is mish-mosh.
The last example in the git-bundle man page might be a bit cryptic but
that is how bundles are expected to be used. To give people repository
access who do not have real network connection other than Sneakernet.
For one shot extraction, defining a remote in the config is overkill and
you could just say:
git ls-remote bundle.bdl
to see what branches it contains and if you are interested in its
master branch and want to merge it to your history, then
git pull bundle.bdl master
should do that.
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Mark Levedahl @ 2008-12-19 19:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: jidanni, git
In-Reply-To: <20081219193256.GU32487@spearce.org>
Shawn O. Pearce wrote:
>
> If the bundle requires 0 refs (like above) then you can init a
> new repository and should be able to fetch from it:
>
> git init
> git pull bundle.bdl master
>
>
With relatively recent git (not sure the version), you can just do
git clone bundle.bdl
Mark
^ permalink raw reply
* Re: How to extract files out of a "git bundle", no matter what?
From: Shawn O. Pearce @ 2008-12-19 19:32 UTC (permalink / raw)
To: jidanni; +Cc: mdl123, git
In-Reply-To: <87iqpgc6bn.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> Someone has handed you a "git bundle".
> How do you get the files out of it?
> If it were cpio, you would use -i, if it were tar, you would use -x...
> You read the git-bundle man page.
> You only get as far as
> # git-bundle verify bundle.bdl
> The bundle contains 1 ref
> d01... /heads/master
> The bundle requires these 0 ref
> bundle.bdl is okay
>
> The rest is mish-mosh. There should be an emergency example for non
> git club members, even starting from apt-get install git-core, of the
> all the real steps needed _to get the files out of the bundle_.
>
> Assume the user _just wants to get the files out of the bundle_ and
> not learn about or participate in some project.
You can't just "get the files out". A bundle contains deltas,
where you need the base in order to recreate the file content.
It can't be unpacked in a vacuum.
To unpack a bundle you need to clone the project and then fetch
from it:
git clone src...
git pull bundle.bdl master
If the bundle requires 0 refs (like above) then you can init a
new repository and should be able to fetch from it:
git init
git pull bundle.bdl master
--
Shawn.
^ permalink raw reply
* How to extract files out of a "git bundle", no matter what?
From: jidanni @ 2008-12-19 19:29 UTC (permalink / raw)
To: mdl123; +Cc: git
Someone has handed you a "git bundle".
How do you get the files out of it?
If it were cpio, you would use -i, if it were tar, you would use -x...
You read the git-bundle man page.
You only get as far as
# git-bundle verify bundle.bdl
The bundle contains 1 ref
d01... /heads/master
The bundle requires these 0 ref
bundle.bdl is okay
The rest is mish-mosh. There should be an emergency example for non
git club members, even starting from apt-get install git-core, of the
all the real steps needed _to get the files out of the bundle_.
Assume the user _just wants to get the files out of the bundle_ and
not learn about or participate in some project.
^ permalink raw reply
* [PATCH] Clarify git-format-patch --in-reply-to
From: jidanni @ 2008-12-19 19:12 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7vzlitho1o.fsf@gitster.siamese.dyndns.org>
Signed-off-by: jidanni <jidanni@jidanni.org>
diff --git a/git-format-patch.txt b/git-format-patch.txt
index ee27eff..04958de 100644
--- a/git-format-patch.txt
+++ b/git-format-patch.txt
@@ -130 +130,2 @@ include::diff-options.txt[]
- provide a new patch series.
+ provide a new patch series. Generates coresponding References and
+ In-Reply-To headers. Angle brackets around <Message-Id> are optional.
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Alan @ 2008-12-19 18:07 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.
Cc: git, Junio C Hamano, Johannes Schindelin, Linus Torvalds
In-Reply-To: <200812182129.01021.bss@iguanasuicide.net>
On Thu, 2008-12-18 at 21:29 -0600, Boyd Stephen Smith Jr. wrote:
> On Thursday 2008 December 18 21:03:46 Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > warning("revert on a merge commit may not do what you "
> > > "expect.");
> >
> > [T]he new warning does
> > not give you enough clue where to go next, so this warning does not give
> > real value. It is pretty much meaningless noise to users.
>
> At least, it might make someone read the manpage again. Still, I'm unhappy
> with the message, but I didn't want to be too wordy. A URL or manpage
> reference would be nice, but I didn't know of a good guide that explained the
> dangers of reverting a merge commit as well as Linus's emails.
That would be OK if the man page actually explained how this is supposed
to work. it does not. (Especially where it concerns "parent number"
and reverts of merges, which has no real explanation.)
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812171233270.28560@intel-tinevez-2-302>
On Wed, Dec 17, 2008 at 5:38 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 17 Dec 2008, Jeff King wrote:
>> If he is planning on doing a separate pyrite implementation, then it
>> _hasn't_ been implemented yet. And I don't care there if he uses hash
>> tables or sorted lists or whatever. I think the most important thing is
>> getting down the design of the _data structure_, so that we can have a
>> compatible implementation inside git itself.
>
> Well, I don't care about pyrite. As far as I am concerned, it might as
> well use an incompatible version. I really don't care.
Well I do care. It would not be a good thing for anyone to have 2 separate
systems for notes. Let us say that someone who you work with uses pyrite
and you don't. They will add notes which you can't see and vice versa.
Thanks,
Govind.
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:38 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <5d46db230812190918qf22b874n8d8aeea557083df8@mail.gmail.com>
Sorry, hit the send key accidentally.
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
> > I agree, I haven't thought of any fix along these lines other than to
> > make gc do the clean up.
>
> I have, and IIRC I briefly mentioned it back then. Basically, you will
>> have to add a "git notes gc" or some such, which basically reads in the
>> whole notes, traverses all reachable commits, marking the corresponding
>> notes, and then writes out all marked notes (leaving the other notes
>> behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
>
This is my concern with keeping a history of the notes pseudo-branch. Let
me restate what you are saying with an example
1) on branch A commit a
2) add note a`
3) on branch B commit b
4) add note b`
5) on branch B commit c
6) add note c`
7) delete branch A
8) gc after a time such that a is pruned
Now either I will always have a note a` as an object forever even though
the only commit that points to it is gone or I have to re-write the history of
the notes branch from the point that it was added.
Given this problem, is it really such a good idea to keep the history?
Of course the other side of this conversation is that the merge operation
will be more complex since the following can also happen
9) push notes
10) user 2 pulls notes but still has commit a and note a`
On the other, other hand, pushing and pulling notes if a history is kept
will have to involve a lot of rebasing/merging.
Just to throw an idea out...
A possible solution is that notes are per-branch,
refs/notes/heads/master
refs/notes/heads/foo/bar
refs/notes/remotes/baz/bang
and then it is easier to deal with. A published branch's notes are isolated
from the changes in unpublished branches. And since published branches
aren't *supposed* to change, then the notes should also always be fast
forwards. Similarly, if a branch is not considered stable, like pu or even
next, then the associated notes branch could be forced in the same way.
Rebase, cherry-pick and merge (and possibly branch/checkout) would have
to be updated to handle notes, which is the down side. It also doesn't solve
the issue of a history causing us to keep notes after the aren't useful anymore.
So perhaps we could use the above layout with no history?
Thanks,
Govind.
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-19 17:18 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20081217101110.GC18265@coredump.intra.peff.net>
On Wed, Dec 17, 2008 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Dec 17, 2008 at 04:43:57AM +0100, Johannes Schindelin wrote:
>
>> > I agree, I haven't thought of any fix along these lines other than to
>> > make gc do the clean up.
>>
>> I have, and IIRC I briefly mentioned it back then. Basically, you will
>> have to add a "git notes gc" or some such, which basically reads in the
>> whole notes, traverses all reachable commits, marking the corresponding
>> notes, and then writes out all marked notes (leaving the other notes
>> behind).
>
> I was thinking something similar, but I think it is even easier. Make
> the rule "if we still have the object, then we still have the note".
> That has three benefits:
>
> - implementation is simple: for each note $n, delete it unless
> has_sha1_file($n).
>
> - it handles notes on non-commit objects
>
> - it kills off notes when an object is _pruned_, not when it stops
> being _reachable_. So if I delete a branch with a commit found
> nowhere else, its notes will hang around until it is actually pruned.
> If I pull it from lost+found, I still keep the notes.
>
> Note that all of this garbage collection of notes is really just
> removing them from the most current notes _tree_. If the notes structure
> is actually composed of commits, then old notes that are "deleted" will
> still be available historically.
>
This is my concern with keeping a history of the notes pseudo-branch. Let
us say that I do the following
1) on branch A commit a
2) add note a`
3) on branch B commit b
4) add note b`
5) on branch B commit c
6) add note c`
7) delete branch A
8) gc after a time such that a is pruned
Now either I will always have anote a`
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: C. Scott Ananian @ 2008-12-19 17:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: David Howells, git, linux-kernel
In-Reply-To: <494B68B8.20107@drmicha.warpmail.net>
On Fri, Dec 19, 2008 at 4:26 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> C. Scott Ananian venit, vidit, dixit 19.12.2008 01:47:
>> On Fri, Dec 12, 2008 at 1:28 PM, David Howells <dhowells@redhat.com> wrote:
>>> Add a guide to using GIT's simpler features.
>>> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
>>> +In the above example, I've assumed that you've got your own tree with the head
>>> +at commit C3, and that you've got a branch that you want to merge, which has
>>> +its head at commit B3. After merging them, you'd end up with a directed,
>>> +cyclic tree:
>>
>> That should be, "acyclic". There are no cycles, because the graph is directed.
>
> Well, directed graphs can have cycles. But the revision graph of a
> revision control system has to be an acyclic directed graph. Otherwise
> parenthood would be a complicated matter ;)
I mean that the example given didn't have a cycle (even though it has
nodes arranged in a circle) because of the orientation of the edges.
But you're right, "directed acyclic graph" is a better correction; the
nodes in git do not form a tree.
--scott
--
( http://cscott.net/ )
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Ivan Zorin @ 2008-12-19 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <494BC89F.9070107@gmail.com>
> does exist some way to check remote git repository for updates without downloading any essential files?
Well, actually, I think, that I've found one of possible soulution already:
First, check remote repo:
$ git ls-remote /path/to/git/repo
<some sha1-hash> HEAD
...
Then check local repo:
$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
<other sha1-hash>
So, if both hashes identical, then current working tree with HEAD, which points to "master", already up-to-dated,
but if they don't, then there is some updates at remote repo.
^ permalink raw reply
* Re: how to check remote git repo for updates without pull/fetch
From: Shawn O. Pearce @ 2008-12-19 16:33 UTC (permalink / raw)
To: Ivan Zorin; +Cc: git
In-Reply-To: <494BC89F.9070107@gmail.com>
Ivan Zorin <ivan.a.zorin@gmail.com> wrote:
> Hello. I have not very hard question, but I don't know how to better do
> it - could you tell me, please, does exist some way to check remote git
> repository for updates without downloading any essential files? I
> suppose, that such command should just type something like: "already
> updated", if current working tree identical to remote repo, and
> something like "there is some updates in remote repo", if remote repo
> has some new commits and/or branches. Thanks.
There aren't any commands to do it.
What you could do is write a script based upon git ls-remote. A
really simple one might be:
#!/bin/sh
remote=$1
o=.git/remote_cache.$remote
n=$o.new$$
git ls-remote $remote >$n
if [ -f $o ]
then
if diff $o $n >/dev/null
then
echo "No changes"
else
mv $n $o
echo "Updates available"
else
mv $n $o
echo "New remote remembered..."
fi
A much more complex one would actually rewrite refs/heads/ to
the correct refs/remotes/ namespace on your local repository and
compare the remote ref values to the local refs/remotes values.
Patches for git fetch --pretend or something might be interesting.
Though I recall a thread about this before on the MLand saying there
was no point. Its not like you can see how big the download would
be until after its over.
--
Shawn.
^ permalink raw reply
* how to check remote git repo for updates without pull/fetch
From: Ivan Zorin @ 2008-12-19 16:15 UTC (permalink / raw)
To: git
Hello. I have not very hard question, but I don't know how to better do
it - could you tell me, please, does exist some way to check remote git
repository for updates without downloading any essential files? I
suppose, that such command should just type something like: "already
updated", if current working tree identical to remote repo, and
something like "there is some updates in remote repo", if remote repo
has some new commits and/or branches. Thanks.
^ permalink raw reply
* Re: jgit doesn't support "compare with" and "replace with"?
From: Shawn O. Pearce @ 2008-12-19 15:20 UTC (permalink / raw)
To: Martin_S; +Cc: git
In-Reply-To: <1229677848765-1677009.post@n2.nabble.com>
Martin_S <iksdrijf@yahoo.com> wrote:
>
> Hi, I'm using eclipse 3.4 and jgit 0.4. The right click context menus don't
> list "compare with" and "replace with". Am I doing something wrong?
We haven't implemented them in EGit. So its not surprising that
they aren't appearing.
--
Shawn.
^ permalink raw reply
* Re: remote tracking branch deletion problem
From: Michael J Gruber @ 2008-12-19 14:56 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191257.18678.thomas.jarosch@intra2net.com>
Thomas Jarosch venit, vidit, dixit 19.12.2008 12:57:
> Hello together,
>
> while playing around with git, I stumbled upon a strange remote tracking
> branch deletion problem. It seems I'm unable to delete the remote tracking
> branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
>
> [tomj@storm repo]$ git init
> Initialized empty Git repository in /tmp/repo/.git/
>
> [tomj@storm repo]$ echo "test" >test
> [tomj@storm repo]$ git add test
> [tomj@storm repo]$ git commit -m "Test"
>
> [tomj@storm tmp]$ git clone repo alice
> Initialized empty Git repository in /tmp/alice/.git/
>
> [tomj@storm alice]$ git branch -r
> origin/HEAD
> origin/master
>
> [tomj@storm alice]$ git branch -r -d origin/HEAD
> Deleted remote branch origin/HEAD.
> [tomj@storm alice]$ git branch -r -d origin/master
> Deleted remote branch origin/master.
>
> [tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
> -rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
> [tomj@storm alice]$ git branch -r
> error: refs/remotes/origin/HEAD points nowhere!
>
> Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
I think the point here is that HEAD is really a symref. "git remote rm
origin" makes sure that symrefs are removed, and is the right command to
use here.
"git branch -r -d", as well as "git update-ref -d" fail to remove HEAD
because it's really not a branch but a symref.
You can use "git update-ref -d --no-deref" to remove HEAD.
Making builtin-branch use delete_ref(,,REF_ISSYMREF) leads to success
for your above commands. I don't know about side effects, though all
tests pass. Is this sensible?
I guess I should come up with a test for this along with the patch.
Michael
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Thomas Jarosch @ 2008-12-19 13:17 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git, Junio C Hamano
In-Reply-To: <8ec76080812190508v2ef0f982pab66a698f06a80d5@mail.gmail.com>
On Friday, 19. December 2008 14:08:23 Whit Armstrong wrote:
> thanks, Thomas. I could definitely pull from your tree. seems like
> the path of least resistance to get my repo split.
Here's the patch I use for git 1.6.0.5. According to Junio
it has the small drawback of always writing out the index,
even if there are no changes.
If you need an updated patch against HEAD, look for Junio's reply
to my patch in the list archive.
Enjoy,
Thomas
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
--- git-1.6.0.5/builtin-update-index.c 2008-12-08 02:21:49.000000000 +0100
+++ git-1.6.0.5.index/builtin-update-index.c 2008-12-13 12:43:14.000000000
+0100
@@ -297,6 +297,8 @@ static void read_index_info(int line_ter
struct strbuf buf;
struct strbuf uq;
+ int found_something = 0;
+
strbuf_init(&buf, 0);
strbuf_init(&uq, 0);
while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
@@ -307,6 +309,8 @@ static void read_index_info(int line_ter
unsigned long ul;
int stage;
+ found_something = 1;
+
/* This reads lines formatted in one of three formats:
*
* (1) mode SP sha1 TAB path
@@ -382,6 +386,11 @@ static void read_index_info(int line_ter
bad_line:
die("malformed index info %s", buf.buf);
}
+
+ /* Force creation of empty index - needed by git filter-branch */
+ if (!found_something)
+ active_cache_changed = 1;
+
strbuf_release(&buf);
strbuf_release(&uq);
}
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Whit Armstrong @ 2008-12-19 13:08 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
In-Reply-To: <200812191044.47830.thomas.jarosch@intra2net.com>
thanks, Thomas. I could definitely pull from your tree. seems like
the path of least resistance to get my repo split.
Cheers,
Whit
On Fri, Dec 19, 2008 at 4:44 AM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Thursday, 18. December 2008 20:51:38 Whit Armstrong wrote:
>> Sorry, seem to be getting this error:
>> `/home/whit/dvl/risk.metrics.utils/RiskMetrics/.git-rewrite/t/../index.new'
>>: No such file or directory
>>
>> do I need to set up the index file first?
>
> Hmm, I guess you have an empty commit in your repository like I did.
> This is currently a corner case in update-index, which does not create empty
> index files. I posted a patch a few days ago and Junio posted an updated
> version of that. I could send you my version for git 1.6.0.5 if you need it.
>
>> Is there a good site that documents this procedure?
>
> A good start is the git-filter-branch man page and the mailinglist archive.
>
> Thomas
>
>
^ 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