> * Even if it does always choose the nicer choice of the two,
>Tony was lucky (no pun intended). Rather, we were lucky that
>Tony was observant. A careless merger may well have easily
>missed this mismerge (from the human point of view).
Actually I can't take credit here. This was
On Wed, 24 Aug 2005, A Large Angry SCM wrote:
> Daniel Barkalow wrote:
> > I'm starting to work on letting the merging process see multiple
> > ancestors, and I think it's messy enough that I should actually discuss
> > it.
> >
> > Review of the issue:
> >
> > It is possible to lost reverts in cas
> So, I've tried cloning, pulling to|from, pushing to|from and resolving
> merges in a repository with undo information stored under
> .git/refs/undo. None of these operations seem to notice the existence
> of this directory. I think this is good.
What I meant was that, when "undo/bar" is a tree
Daniel Barkalow wrote:
> I'm starting to work on letting the merging process see multiple
> ancestors, and I think it's messy enough that I should actually discuss
> it.
>
> Review of the issue:
>
> It is possible to lost reverts in cases when merging two commits with
> multiple ancestors, in the
Is there a convention of where/how it is safe to store additional
(non-git) data in $GIT_DIR?
The arch import needs to keep a cache with arch-commit-id =
git-commit-id mappings, and some notes about what patch-trading Arch
recorded. It'd be great to be able to store those in
$GIT_DIR/archimport/
On 8/25/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Have fun.
Yay!
> What to expect after 0.99.5
> ===
> Documentation
> -
Perhaps link the 'howto' docs from the git formal docs, so they are
visible via http://www.kernel.org/pub/software/scm/git/docs/
>
I'm starting to work on letting the merging process see multiple
ancestors, and I think it's messy enough that I should actually discuss
it.
Review of the issue:
It is possible to lost reverts in cases when merging two commits with
multiple ancestors, in the following pattern: (letters representi
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In fact, the case that git selected ("patch applied"), is not only the one
> that is very fundamentally the one git will always select in this kind of
> situation - in some respects is actually the nicer choice of the two.
While I appreciate the excuse
Well, both are good ideas. Both are stack oriented, though.
I see what you mean about adding an undo directory to .git/refs/. I
will do some tests... (read further)
On Wed, Aug 24, 2005 at 03:48:21PM -0700, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Generally, ea
I've pushed out all of what has been in the proposed updates
branch, along with documentation updates.
Many changes all over:
- pulling from packed repository.
- cvsimport.
- documentation coverage.
- usability.
- terminology clarification.
- hooks for updates and commits.
- updated gitk.
Tim Ottinger <[EMAIL PROTECTED]> writes:
> So when this gets all settled, will we see a lot of tool renaming?
I personally do not see it coming. Any particular one you have
in mind?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
M
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Generally, each subdirectory of refs/ has refs to objects of the same
> type, and heads/ is commits, but other directories are other things. tags/
> is all tag objects, and you could have undo/ be trees.
That's OK from the prune front, but I am not su
I'm sorry for sending a non-working patch. Apparently I got lost in /tmp.
So here is the patch for gitk that allows you to browse the entire tree for
every revision.
The patched gitk script and some screenshots can be found at:
http://public.efil.de/gitk/
For my personal use it's rather su
Earlier rounds broke 'whatchanged -p'. In attempting to fix this,
make two axis of output selection in rev-parse orthogonal:
--revs-only tells it not to output things that are not revisions nor
flags that rev-list would take.
--no-revs tells it not to output things that
Some callers to rev-parse were using the output selection flags
inconsistently.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-bisect-script |4 ++--
git-branch-script |2 +-
git-log-script |2 +-
git-request-pull-script |4 ++--
git-revert-script
On Wed, 24 Aug 2005, Carl Baldwin wrote:
> This is interesting. Can a ref be to a tree rather than a commit? And
> it still works? I guess it would. I hadn't thought about that.
Generally, each subdirectory of refs/ has refs to objects of the same
type, and heads/ is commits, but other direct
This is interesting. Can a ref be to a tree rather than a commit? And
it still works? I guess it would. I hadn't thought about that.
Will prune preserve any tree mentioned in any file in refs? How does
this work exactly?
Cheers,
Carl
On Wed, Aug 24, 2005 at 04:44:48PM -0400, Daniel Barkalow
On Wed, 24 Aug 2005, Carl Baldwin wrote:
> This brings up a good point (indirectly). "git prune" would destroy the
> undo objects. I had thought of this but decided to ignore it for the
> time being.
If you made undo store the tree under refs somewhere, git prune would
preserve it.
-Da
>I think git did the "right thing", it just happened to be the thing that
>Tony didn't want. Which makes it the "wrong thing", of course, but from a
>purely technical standpoint, I don't think there's anything really wrong
>with the merge.
On the plus side ... at least it wasn't a dumb user error
On Wed, Aug 24, 2005 at 11:18:42AM -0700, Junio C Hamano wrote:
> Carl Baldwin <[EMAIL PROTECTED]> writes:
>
> > Attached are the two scripts. Comments and criticism are welcome.
>
> An obligatory non-technical comment. I would have liked to see
> this not in a MIME multipart format, which made
On Wed, Aug 24, 2005 at 11:51:32AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 24 Aug 2005, Carl Baldwin wrote:
> >
> > Oops. I forgot to actually exit from the script if git-diff-files is
> > non-empty.
> >
> > Also, looking at it now, I don't think keeping undo information in a
> > stack is th
On Wed, 24 Aug 2005, Linus Torvalds wrote:
> Now, if the shared patch hadn't been a patch, but a shared _commit_, then
> the thing would have been unambiguous - the shared commit would have been
> the merge point, and the revert would have clearly undone that shared
> commit.
Actually, it was a s
On Wed, 24 Aug 2005, Junio C Hamano wrote:
> that is not a right thing so get rid of that assumption" (which
> I agree is a good change", and the last sentense says
> opposite...
Well, the patch makes it an _explicit_ assumption, instead of a very
subtly hidden one from the code-flow. It was th
On Wed, 24 Aug 2005, Carl Baldwin wrote:
>
> Oops. I forgot to actually exit from the script if git-diff-files is
> non-empty.
>
> Also, looking at it now, I don't think keeping undo information in a
> stack is the right thing. But keeping more than just one would be good.
> Oh well, my first
On Wed, 24 Aug 2005, Linus Torvalds wrote:
>
> Basically, he had two branches, A and B, and both contained the same patch
> (but _not_ the same commit). One undid it, the other did not. There's no
> real way to say which one is "correct", and both cases clearly merge
> perfectly, so both outcom
Linus Torvalds <[EMAIL PROTECTED]> writes:
> The --flags cleanup caused problems: we used to depend on the fact that
> "revs_only" magically suppressed flags, adn that assumption was broken by
> the recent fixes.
>
> It wasn't a good assumption in the first place, so instead of
> re-introducing
On Wed, 24 Aug 2005, Junio C Hamano wrote:
>
> This does not have much to do with which common ancestor
> merge-base chooses. Sorry, I am not sure what is the right way
> to resolve this offhand.
I think git did the "right thing", it just happened to be the thing that
Tony didn't want. Which m
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
>
>> But --soft, --hard looks rather confusing to me.
>>
>> Something like --force or --prune may be a bit more intuitive, and let
>> default behaviour be the one you name --soft for now.
>
> I do not have object
On Wed, 24 Aug 2005, Junio C Hamano wrote:
>
> Added at the end of git-repack-script (Linus can disable it by
> giving an '-n' flag when packing his private repositories).
No, I just haven't updated my git on master.kernel.org in a while. So
nothing to disable.
I ran git-update-server-info ma
Carl Baldwin <[EMAIL PROTECTED]> writes:
> Attached are the two scripts. Comments and criticism are welcome.
An obligatory non-technical comment. I would have liked to see
this not in a MIME multipart format, which made commenting on it
a bit harder than necessary.
> Content-Type: text/plain;
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> It looks like pack-c24bb5025e835a3d8733931ce7cc440f7bfbaaed isn't in the
> pack list. I suspect that updating this file should really be done by
> anything that creates pack files, because people forget to run the program
> that does it otherwise and t
Oops. I forgot to actually exit from the script if git-diff-files is
non-empty.
Also, looking at it now, I don't think keeping undo information in a
stack is the right thing. But keeping more than just one would be good.
Oh well, my first shot is never perfect. ;-)
Carl
On Wed, Aug 24, 2005 a
Hello,
So, one thing that I liked about GNU Arch when I tried it out was the
ability to undo and redo changes in the local working copy. I decided
to try to do this with git. What I have is preliminary. I'm sure it
could use some work.
So, I started with the assumption that all changes in the
On Wed, 24 Aug 2005, Martin Schlemmer wrote:
> Hi,
>
> Recently cogito again say that the rsync method will be deprecated in
> future (due to http-pull now supporting pack objects I suppose), but it
> seems to me that it still have other issues:
>
> -
> lycan linux-2.6 # git pull origin
> Fetc
Hi,
Recently cogito again say that the rsync method will be deprecated in
future (due to http-pull now supporting pack objects I suppose), but it
seems to me that it still have other issues:
-
lycan linux-2.6 # git pull origin
Fetching HEAD using http
Getting pack list
error: Couldn't get 057
On Wed, 24 Aug 2005, Junio C Hamano wrote:
> [EMAIL PROTECTED] writes:
>
> > So I have another anomaly in my GIT tree. A patch to
> > back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
> > in my release branch at commit
> >
> > 62d75f3753647656323b0365faa43fc1a8f7be97
> >
> > appears
So when this gets all settled, will we see a lot of tool renaming?
While it would cause me and my team some personal effort (we have
a special-purpose porcelain), it would be welcome to have a lexicon
that is sane and consistent, and in tune with all the documentation.
Others may feel different
Gave the code another pass. The code should be more readable, and make
a bit more sense.
It now:
- handles commit timestamps correctly
- handles binary files correctly
- uses parselog() to tell git-update-cache what's been
added/deleted/modified - much faster commits on large trees
- gets the
But cg-clone git.git sucess:
cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/
defaulting to local storage area
17:39:36
URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/refs/heads/master
[41/41] -> "refs/heads/.origin-pulling" [1]
progress: 3 objects, 53
[EMAIL PROTECTED] writes:
> So I have another anomaly in my GIT tree. A patch to
> back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
> in my release branch at commit
>
> 62d75f3753647656323b0365faa43fc1a8f7be97
>
> appears to have been lost when I merged the release branch to
> the t
40 matches
Mail list logo
