Re: Pytave - (probably mercurial) - - Question

[Abhinav Tripathi]

> I'm not sure what you mean here either. Can you give an example of what
> exact commands you would be using in git that you are trying to ask
> about here?
>
> It sounds like you've done this
>
>   # edit some files
>   hg commit
>   hg book mybookmark
>
> Now 'mybookmark' points to the changes you just committed.

Not quite. It's like the commits are not in any bookmark and are just lying on 'default'  branch (i guess).
I need a bookmark which i will get from '@' and then want to add the 2 commits to that bookmark. (they do not have any merge conflicts)

>
> This means that your repository's '@' bookmark is different from the
> bookmark of the same name that you pulled from. This is kind of like
> remote tracking branches in git, hg does not have any concept of remote
> tracking branches.
>
> This means that Alice has pushed a change to her '@' bookmark, and Bob
> has pushed a different change to his '@' bookmark, and Bob pulls from
> Alice and gets a new bookmark '@alice' to mark the two heads.

Oh ok. I will have to first check. I thought I didn't change anything but still got this.

> Yes. `hg pull` is like `git fetch`, it downloads new changes but doesn't
> actually change your working directory or your concept of what revision
> you are working on. `hg update` is exactly like `git checkout`, it
> updates your working revision, and attempts to merge any uncommited
> local changes.
>
> In fact `hg checkout` is an alias for `hg update` if you like that
> terminology better.

Thanks. I didn't know this.

> This would probably also be clearer if you showed an example of what you
> are trying to do in git commands.
>
> It sounds like you are pulling from your repository and getting some
> commits with bookmark 'foo'. You have meanwhile committed some local
> commits with bookmark 'bar'. Are they separate features that you want to
> push separately to be merged by someone else, one set of changes is
> independent from the other? Or do you want to either rebase or merge the
> new commits such that there is a new commit on 'foo' that includes the
> new changes from 'bar'?
>
> Do you want the end result to look like this
>
>   '@' --- o --- o --- 'foo'
>      \
>        --- o --- 'bar'
>
> or like this
>
>   '@' --- o --- o --- 'foo' --- o
>      \                         /
>        --- o --- 'bar' -------
>
> or like this
>
>   '@' --- o --- o --- 'foo' --- o --- 'bar'

The last one is what i want. (keeping in mind that 'foo'  and 'bar'  are just tags and will disappear. 'o'  are the actual commits which will remain)

> Yes, hg has no concept of a "staging area" like git does. Just use
>
>   hg commit file1 file2 ...
>
> This has actually bitten me several times, especially when amending a
> commit and I forget that I had local uncommitted changes.

Thanks. Didn't know this too.

.
Abhinav