On segunda-feira, 4 de abril de 2016 10:25:16 PDT Welbourne Edward wrote:
> $ git stash
> $ git pull -r
> $ git stash pop
Also:
$ git fetch
$ git rebase --autostash
It's exactly the same.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Cen
I mentioned:
>> merge-base - if you have a strict tree, this isn't a merge, so it's
>> where one was branched off the other, but nothing about the merge-base
>> or any of its ancestors contains any hint as to which branch it was on
>> when it was committed.
René J.V. Bertin replied:
> In short, th
> Forgot - maybe a stupid question, but can you set up a topic branch to
> track a remote branch (and would that make sense)?
$ git checkout -b topic remote/branch
will, by default, set up topic so that, while it's checked out, git pull
fetches remote/branch to merge with it (or rebase it onto) a
Forgot - maybe a stupid question, but can you set up a topic branch to track a
remote branch (and would that make sense)?
R
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Monday April 04 2016 11:56:23 Welbourne Edward wrote:
>You can even use: git log --graph
>if you can cope with ASCII art ;-)
As long as it doesn't include cows ;)
>merge-base - if you have a strict tree, this isn't a merge, so it's
>where one was branched off the other, but nothing about the
René J.V. Bertin
> I've seen graphical utilities that attempt to show the branch
> hierarchy in some kind of tree,
You can even use: git log --graph
if you can cope with ASCII art ;-)
> but apparently miss from `git help branch` if it's possible to know
> the origin branch of a topic branch. Is i
On Monday April 04 2016 10:25:16 Welbourne Edward wrote:
More very useful info, thanks!
> For three-way diffs between two commits and their most recent common
> ancestor, you can use git diff $topic...$other, if you're comfortable
> reading three-way diffs,
I could be - using a side-by-side visu
In response to:
>>> What works well for me e.g. before doing a commit is what I think of
>>> as manual rebasing: I remove my patches one way or another, git-pull,
>>> and then reapply the patch(es).
I offered:
>> That's pretty much exactly what
>>
>> $ git pull -r
>>
>> (a.k.a. --rebase) will do f
04.04.2016, 12:32, "René J. V. Bertin" :
> Welbourne Edward wrote:
>
> Hi,
>
>>> What works well for me e.g. before doing a commit is what I think of
>>> as manual rebasing: I remove my patches one way or another, git-pull,
>>> and then reapply the patch(es).
>>
>> That's pretty much exactly
Welbourne Edward wrote:
Hi,
>> What works well for me e.g. before doing a commit is what I think of
>> as manual rebasing: I remove my patches one way or another, git-pull,
>> and then reapply the patch(es).
>
> That's pretty much exactly what
>
> $ git pull -r
>
> (a.k.a. --rebase) will do f
Thiago Macieira wrote:
> git diff misses the parent commit ID and the commit message. The output from
> git format-patch has the commit message, but still misses the parent commit
> ID.
So? A system that accepts patches rather than commits will evidently need and
provide a mechanism to enter at
On Wednesday, 30 March 2016 18:14:38 CEST, Konstantin Tokarev wrote:
New UI is not required to use these features
Inline editting is only available in 2.11, and the old change screen is
gone in 2.11, too.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
On Wednesday March 30 2016 15:51:49 Welbourne Edward wrote:
> I met such a review tool once.
> It was actually horribly frustrating.
> I'd much sooner be using critic [0].
I am a regular user of KDE's Reviewboard. It's undoubtedly not ideal, but I
find it more than powerful enough.
> I'm afraid
30.03.2016, 19:11, "Thiago Macieira" :
> On quarta-feira, 30 de março de 2016 17:00:20 PDT René J.V. Bertin wrote:
>> It also illustrates very nicely why I'll keep thinking that it'd be so much
>> easier if Qt had a review system to which you can upload the (possibly
>> pruned) results of `git
On quarta-feira, 30 de março de 2016 17:00:20 PDT René J.V. Bertin wrote:
> It also illustrates very nicely why I'll keep thinking that it'd be so much
> easier if Qt had a review system to which you can upload the (possibly
> pruned) results of `git diff` (and download it again if needed).
git di
> Thanks for such a lengthy and detailed overview - I hope you had that
> sitting around somewhere! :)
heh - I touch-type at speed and have all of that in my head.
I learned git under demanding circumstances, so learned it thorouhgly.
> It also illustrates very nicely why I'll keep thinking that
On Wednesday March 30 2016 12:54:30 Welbourne Edward wrote:
>René J.V. Bertin said:
>> I've got a few things I'd like to put up for code review, which I've
>> been putting off because I can only think of doing them either one by
Hi,
Thanks for such a lengthy and detailed overview - I hope you
René J.V. Bertin said:
> I've got a few things I'd like to put up for code review, which I've
> been putting off because I can only think of doing them either one by
> one (carrying each to completion before moving on to the next) or by
> using parallel working copies. Neither is what I'd call effi
18 matches
Mail list logo
