Nico Williams n...@cryptonector.com writes:
On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov o...@javad.com wrote:
Nico Williams n...@cryptonector.com writes:
That exception aside, keeping all local commits on top by always
rebasing them onto the upstream is extremely useful: a) in simplifying
Nico Williams n...@cryptonector.com writes:
On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov o...@javad.com wrote:
Nico Williams n...@cryptonector.com writes:
Local merge commits mean that you either didn't rebase to keep all
your local commits on top of the upstream, or that you have multiple
Nico Williams n...@cryptonector.com writes:
On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Sergei Organov wrote:
Is there any scenario at all where pull --rebase=true wins over
preserve?
Basically always in my book. ;-)
When people turn on 'pull --rebase
Jonathan Nieder jrnie...@gmail.com writes:
David Besen wrote:
Jonathan Nieder wrote:
This is how pull --rebase works. It turns your single-parent commits
into a sequence of patches on top of upstream and completely ignores
your merge commits.
There is a --rebase=preserve option that
Jonathan Nieder jrnie...@gmail.com writes:
Sergei Organov wrote:
Is there any scenario at all where pull --rebase=true wins over
preserve?
Basically always in my book. ;-)
When people turn on 'pull --rebase', they are asking for a clean,
simplified history where their changes are small
Hello,
$ git --version
git version 1.9.3
Please consider the following history:
--C--
/ \
/ M topic,HEAD
/ /
A---B master
shouldn't
$ git rebase master
be a no-op here? According to my reading of the rebase manual page, it
should be a no-op, as 'topic' is a
Jonathan Nieder jrnie...@gmail.com writes:
Hi Sergei,
Sergei Organov wrote:
--C--
/ \
/ M topic,HEAD
/ /
A---B master
shouldn't
$ git rebase master
be a no-op here?
[...]
I'd expect --force-rebase to be required for this to happen:
-f, --force-rebase
Hello,
Just playing with it, got some surprises:
$ git --version
git version 1.9.3
$ git describe --all
heads/v3.5
$ git describe --all --match 'v*'
tags/v3.5.6b2-4-gab4bf78
$ git describe --all --match 'heads/v*'
fatal: No names found, cannot describe anything.
... heads/v3.5 matches neither
Junio C Hamano gits...@pobox.com writes:
Sergei Organov o...@javad.com writes:
Will something break if it won't helpfully prepend refs/tags/ once
--all is given?
describe --all --match 'v*' will no longer match a tag v1.2.3, and
forces the users to say describe --match 'refs/tags/v
Hello,
After convertion of a project from CVS to git, I'd like to rename some
references in the created git repository (before it's published, so no
problems here). Is there a plumbing that would do:
git rename-ref old_name new_name
for me?
For reference, the (ugly) solution I currrently use
John Keeping j...@keeping.me.uk writes:
On Fri, May 23, 2014 at 02:11:55PM +0400, Sergei Organov wrote:
Hello,
After convertion of a project from CVS to git, I'd like to rename some
references in the created git repository (before it's published, so no
problems here). Is there a plumbing
Arup Rakshit arupraks...@rocketmail.com writes:
[...]
Now you can see, that I have created, a new file called *file.txt*, in the
*master branch*.
And here is your basic misunderstanding. You've created file.txt indeed,
but not in the *master branch* (or any branch). You've created it in the
Hello,
Was writing conversion script from CVS to git for my repo and noticed
slight inconsistency in git-tag, git-branch, and git-update-ref behavior:
$ git --version
git version 1.9.3
$ git tag -d echo success
success
$ git branch -d echo success
fatal: branch name required
$ git update-ref
13 matches
Mail list logo
