On Tue, 23 Aug 2005, Tony Luck wrote:
>
> So GIT decides that the test branch has had a patch, and the release
> branch hasn't ... and so it merges by keeping the version in test.
>
> Plausible?
Very. Sounds like what happened.
Linus
-
To unsubscribe from this list: send the l
I'm at home, and too lazy to log in to work to look at my tree. But I
have a theory
as to what went wrong for me.
At the start I had a file, same contents in test and release branch.
I applied a patch to release, and pulled to test. So the contents are still
the same, both with the patch applie
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Ok, I think your approach is the correct one. Just list all the commits,
> and let the merge logic figure out which one is the best one.
>
> Just returning several entries is the correct thing to do, because then
> you can make the distance function be
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This makes "--revs-only" imply "--no-flags".
>
> [ Side note: we might want to get rid of these confusing two-way flags,
> where some flags say "only print xxx", and others say "don't print yyy".
> We'd be better off with just three flags that say
On Tue, 23 Aug 2005, Junio C Hamano wrote:
> Only lightly tested, in the sense that I did only this one case
> and nothing else. For a large repository and with complex
> merges, "merge-base -a" _might_ end up reporting many
> candidates, in which case the pre-merge step to figure out the
> best
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> Yes it can. GIT does not care if the commit ancestry does not
> make sense in contents terms (i.e. you can record one tree
> object in a commit object, and record another, completely
> unrelated tree object in a commit object that has the first
> c
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 it, let's just get rid of it.
This makes "--revs-onl
On Tue, 2005-08-23 at 21:07 -0400, Junio C Hamano wrote:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> > Probably the ideal way would be to give merge-base an option to
> > spit out all the candidates, and have the script try to see
> > which ones yield the least number of non-trivial merges.
>
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> Only lightly tested, in the sense that I did only this one case
> and nothing else. For a large repository and with complex
> merges, "merge-base -a" _might_ end up reporting many
> candidates, in which case the pre-merge step to figure out the
> b
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Probably the ideal way would be to give merge-base an option to
> spit out all the candidates, and have the script try to see
> which ones yield the least number of non-trivial merges.
I first checked out your 702c7e.. commit, and slurped Linus tip
(ba
On Tue, 23 Aug 2005, Len Brown wrote:
>
> I'm having trouble using git for merging kernel trees.
>
> git seems to manufacture conflicts in files that
> I never touched, and on some files it completely
> throws up its arms, see "Not handling case" below.
Cool.
You've found a case where git-merg
At Tue, 23 Aug 2005 17:22:47 -0700,
Junio C Hamano wrote:
>
> Yasushi SHOJI <[EMAIL PROTECTED]> writes:
>
> > for --hard option, what you want to do is to completely revert the
> > current state of your index file and work tree to known point.
> >
> > for that, how about git-revert-script?
>
> "
Junio C Hamano <[EMAIL PROTECTED]> writes:
> I think merge-base, even though we attempted to fix it recently,
> is still confused and that is one of the reasons why you are
> getting this.
>
> prompt$ git-rev-parse origin test-lenb-merge
> 81065e2f415af6c028eac13f481fb9e60a0b487b
> 70
On Tue, 2005-08-23 at 19:58 -0400, Junio C Hamano wrote:
> Len Brown <[EMAIL PROTECTED]> writes:
>
> >> I could get to 81065e2f415af6... commit (Linus tip at this
> >> moment), so if you can tell me where to snarf the other commit
> >> (702c7e76) that would help me diagnose the problem a lot.
Catalin Marinas <[EMAIL PROTECTED]> writes:
> What's the definition of a parent in GIT terms? What are the
> restriction for a commit object to be a parent? Can a parent be an
> arbitrarily chosen commit?
Yes it can. GIT does not care if the commit ancestry does not
make sense in contents terms
Yasushi SHOJI <[EMAIL PROTECTED]> writes:
> for --hard option, what you want to do is to completely revert the
> current state of your index file and work tree to known point.
>
> for that, how about git-revert-script?
"git revert" is to create a commit that reverts a previous
commit, which I thi
The "verify_pathspec()" function doesn't test for ending NUL character in
the pathspec, causing some really funky and unexpected behaviour. It just
happened to work in the cases I had tested.
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
diff --git a/ls-files.c b/ls-files.c
--- a/ls-fil
At Tue, 23 Aug 2005 15:08:44 -0700,
Junio C Hamano wrote:
>
> 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.
>
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I think that git-read-tree -u ought to remove a directory if it removes
> the last file (or directory) in it.
I concur and do not have much objections to a patch that would
do so.
-
To unsubscribe from this list: send the line "unsubscribe git" in
th
Len Brown <[EMAIL PROTECTED]> writes:
>> I could get to 81065e2f415af6... commit (Linus tip at this
>> moment), so if you can tell me where to snarf the other commit
>> (702c7e76) that would help me diagnose the problem a lot.
>
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/to-akpm.
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 test branch at commit
0c3e091838f02c537c
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> The thing that this doesn't do is remove empty directories when the last
> file is deleted. I once expressed the opinion in a previous thread that
> directories should be added and removed explicitly in git. (Thus
> allowing an empty directory to be add
On Tue, 2005-08-23 at 18:06 -0400, Junio C Hamano wrote:
> Len Brown <[EMAIL PROTECTED]> writes:
>
> > The merge issue below is reproduced in a "git clone -l" copy
> > with no plain files present.
>
> Meaning you did not have any file in the working tree? It seems
> to me that what is happenning
Ok, the following is what I came up with based on your response. This
is .git/hooks/update. It mostly works in my situation. See below for
my discussion on what didn't work.
#!/bin/sh
export PATH=/usr/local/bin:/usr/bin:/bin
# cd to the root of the project directory (assume one dir up from GI
On Tue, 23 Aug 2005, Jan Veldeman wrote:
> Daniel Barkalow wrote:
>
> > On Tue, 23 Aug 2005, Catalin Marinas wrote:
> >
> > Something is legitimate as a parent if someone took that commit and did
> > something to it to get the new commit. The operation which caused the
> > change is not specified.
Daniel Barkalow <[EMAIL PROTECTED]> writes:
>> > If you don't use -f, git-checkout-script removes deleted files. Using -f
>> > tells it to ignore the old index, which means that it can't tell the
>> > difference between removed files and files that weren't tracked at all.
Yes and no. "git checko
Len Brown <[EMAIL PROTECTED]> writes:
> The merge issue below is reproduced in a "git clone -l" copy
> with no plain files present.
Meaning you did not have any file in the working tree? It seems
to me that what is happenning is the resolve is trying to merge
the head of your tree and from-linus
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 objections to removing --mixed, but I do not find
--force/--
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> The point is to push and use a post-update hook to do the checkout. So,
> this won't be possible.
You could have the remote repository be something like
"~/git/website.git", and have a hook which does: "cd ~/www; git pull
~/git/website.git/". That is, h
On Tue, Aug 23, 2005 at 05:27:12PM -0400, Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Carl Baldwin wrote:
>
> > On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> > > On Tue, 23 Aug 2005, Carl Baldwin wrote:
> > >
> > > > Hello,
> > > >
> > > > I recently started using git to rev
Hello!
This patch changes cg-pull so that if the branch is not specified, it
takes origin's .git/HEAD without first trying .git/refs/heads/master.
This removes preferential treatment of the "master" branch, allowing the
upstream to use another name for the default branch. To get the master
branch
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> > On Tue, 23 Aug 2005, Carl Baldwin wrote:
> >
> > > Hello,
> > >
> > > I recently started using git to revision control the source for my
> > > web-page. I wrote a post-update hook to ch
And Junio C Hamano writes:
- > BTW, how would people feel about replacing the
- > setenv() and unsetenv() calls with the older putenv()?
- No comment on this one at this moment until I do my own digging
- a bit.
If you're interested, I have a few patches in
http://www.cs.berkeley.edu/~ejr/g
Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Catalin Marinas wrote:
>
> Something is legitimate as a parent if someone took that commit and did
> something to it to get the new commit. The operation which caused the
> change is not specified. But you only want to include it if anyone cares
> abo
Sometimes the git-read-tree in git-checkout-script fails for me.
Make sure that the failed status is passed up to caller.
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
diff --git a/git-checkout-script b/git-checkout-script
--- a/git-checkout-script
+++ b/git-checkout-script
@@ -72,4 +72,6 @@
I'm having trouble using git for merging kernel trees.
git seems to manufacture conflicts in files that
I never touched, and on some files it completely
throws up its arms, see "Not handling case" below.
Not clear how I got into this state -- probably
something to do with adding commits on branch
I'm a little closer to understanding how I got into the situation
where I made that ugly commit last week that included 10 files that
I didn't want, because I just had another failed merge (but this
time I know how to recover :).
The approximate sequence of events was:
SGI told me one of the pend
On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Carl Baldwin wrote:
>
> > Hello,
> >
> > I recently started using git to revision control the source for my
> > web-page. I wrote a post-update hook to checkout the files when I push
> > to the 'live' reposito
> I am not sure what mixed reset (the current behaviour) is good
> for. If nobody comes up with a good use case it may not be a
> bad idea to remove it.
Using the principle of minimum suprise the --mixed should be removed.
--soft - undo the commit leaving all changes.
--hard - undo the commit and
On 8/23/05, Alex Riesen <[EMAIL PROTECTED]> wrote:
> On 8/17/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
> > you have people who do
>
> BTW, could this (below) be useful for something?
>
Well, a bit of explanation i
On 8/17/05, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
> you have people who do
BTW, could this (below) be useful for something?
#include
#include
#include
// an analog of "cd path" from a directory "cwd".
char* pathe
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> Hello,
>
> I recently started using git to revision control the source for my
> web-page. I wrote a post-update hook to checkout the files when I push
> to the 'live' repository.
>
> In this particular context I decided that it was important to me to rem
On Tue, 23 Aug 2005, Catalin Marinas wrote:
> > So the point is that there are things which are, in fact, parents, but we
> > don't want to list them, because it's not desired information.
>
> What's the definition of a parent in GIT terms? What are the
> restriction for a commit object to be a pa
On Tue, 23 Aug 2005, Linus Torvalds wrote:
>
> Try this trivial patch, it should work better.
Actually, don't do the "show_default()" part of this. We should _not_ show
the default string if we haev "--no-revs" and the string doesn't match a
rev.
Also, this fixes "--" handlign with "--flags"
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> So far, the following commands should be usable with relative directory
> paths:
>
> update-cache
> ls-files
> diff-files
> diff-cache
> diff-tree
Also, git-rev-parse.
Finally, this trivial patch makes "git-rev-list" also able
Some people may have noticed that the progress of the master
branch head has somewhat slowed down lately, and I have kept
some changes in the proposed updates branch for quite some time.
There are two reasons for this. One is that I've been quite
busy during my day job hours, and haven't had enou
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> I have been looking at what git-rev-parse does and could not
> figure out a way to convince it to give me only arguments with
> a '-' prefix.
Gaah. Understandable. It got broken during some cleanup.
Try this trivial patch, it should work better.
N
Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> One factor not mentioned there is that, as things move upstream, we often
> want to discard a lot of history; if someone commits constantly to deal
> with editor malfunction or something, we don't really want to take all of
> this junk into the project h
Hello!
suggest_hardlink is write-only in cg-pull - remove it. can_hardlink
should not be shown to the user as is (it's either "l" or empty) - we
should output something meaningful instead.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
Hello,
I recently started using git to revision control the source for my
web-page. I wrote a post-update hook to checkout the files when I push
to the 'live' repository.
In this particular context I decided that it was important to me to remove
deleted files after checking out the new HEAD. I
Hello,
Here's a thought. It might be nice, in this situation, to have
something like a git-undo-script that can undo the changes in the index
storing them in a tree object but not wrapping them into a commit. A
ref to the tree can be stored in an 'undo' file somewhere under .git.
When the merge
On 8/24/05, Martin Langhoff <[EMAIL PROTECTED]> wrote:
> First draft of an Arch import.
And now, with sample script attached, too.
cheers,
martin
git-archimport-script
Description: Binary data
First draft of an Arch import. Very limited but will import one
"branch" into one head. The basics are for it to follow branches, and
some support for marking merges (or at least what git would consider
merges.
TODO:
- proper branch switching
- binary file handling
- get the date format right!
- p
Hi.
This is a quick hack which allows you to browser the entire tree using gitk.
Keybindings: n - toggle line numbers
v - toggle tree view
I know, it should be cleaned up. It needs some locking.
Colored diffs in the tree would be nice.
Is anybody interested in a propper version
It's sometimes unclear which head is "ahead" of the other. If I get
the order wrong, cg-log shows no log output. Is this expected?
I was expecting a warning, or a reverse-ordered log. Or both. ;)
martin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
I have been looking at what git-rev-parse does and could not
figure out a way to convince it to give me only arguments with
a '-' prefix. Specifically, I wanted to remove the hardcoded -p
and -M flags from git-diff-script. Running
$ sh -x git-diff-script -C HEAD^ HEAD
reveals that none of t
56 matches
Mail list logo
