On Wed, Dec 20, 2017 at 12:43:37PM +0100, Josef Wolf wrote:
> Thanks to you both for your patience with me. Sorry for the late reply, my day
> job was needing me ;-)
>
> On Fri, Dec 15, 2017 at 07:58:14PM +0100, Igor Djordjevic wrote:
> > On 15/12/2017 17:33, Ju
s, I'd still like to learn how to do it correctly.
Never doing local modifications in the "live" directories would require to
install test systems and simulate their environment just for doing some minor
adjustments.
--
Josef Wolf
j...@raven.inka.de
the mix, to "silence" actually still unresolved merge
> conflicts, making next script execution possible, make sense?
>
> Yes, `git diff` won`t be the same as if conflicts were still in, but
> it might be worth it in this specific case, conflicting parts still
> easily visible between conflict markers.
That means, the conflict is still there, but git would think this is an
ordinary modification?
--
Josef Wolf
j...@raven.inka.de
ight there where cron executes has the benefit that
cron uses the same modifications which I am using. This way, whenever cron
decides to execute, it is exactly the same as if I would do a "make run" on
the command line. Since all the scripts are designed to be idempotent,
everything wor
have
been changed upstream. With git-stash, EVERY locally modified file is at risk.
> I`m thinking of a workflow involving (scripted) creation of a
> temporary branch at fetched remote branch position, and using
> something like `git checkout --merge ` to merge your
> local modifications to latest changes fetched from remote (ending up
> with conflicts inside working tree, if any),
But this would require local modifications to be committed?
--
Josef Wolf
j...@raven.inka.de
have an option to specify "remote
is ahead of me". How would I properly check whether a merge is actually needed?
--
Josef Wolf
j...@raven.inka.de
worse: if I happen to save
one of the modified files while the modifications are in the stash, the
"git stash pop" will definitely cause a conflict, although nothing really
changed.
So, how would I get this workflow with git? Is it possible to emulate the
behavior of "svn update"?
Any ideas?
--
Josef Wolf
j...@raven.inka.de
to recover?
Any ideas?
PS: this is git-1.8.1.4.
--
Josef Wolf
j...@raven.inka.de
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 14, 2014 at 07:59:18PM +0700, Duy Nguyen wrote:
On Fri, Feb 14, 2014 at 7:45 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Josef Wolf j...@raven.inka.de writes:
Notice the refs/heads _within_ refs/heads!
Probably you did something like git branch refs/heads/master. You can
On Fri, Feb 14, 2014 at 04:35:14PM +0100, David Kastrup wrote:
Josef Wolf j...@raven.inka.de writes:
The only command in this script that uses heads is
git symbolic-ref HEAD refs/heads/$new_branch
You probably should check how $new_branch comes about.
This is the line of code where
delibaretly cuts off this
prefix in some situations.
I don't think my problem stems from something like git branch
refs/heads/master
Anyway, some clarifications about the usage of this prefix would be great!
--
Josef Wolf
j...@raven.inka.de
--
To unsubscribe from this list: send the line
On Tue, Sep 24, 2013 at 03:36:13AM -0400, Jeff King wrote:
On Fri, Sep 20, 2013 at 11:27:15AM +0200, Josef Wolf wrote:
Even without asking, we can assume with great probability that
origin/somebranch is available at origin.
Bear in mind that the transfer process does not know about
cherry
On Mon, Sep 16, 2013 at 05:55:36PM -0400, Jeff King wrote:
On Fri, Sep 13, 2013 at 12:09:35PM +0200, Josef Wolf wrote:
I'm not sure I understand correctly. I see that bitmaps can be used to
implement set operations. But how comes that walking the graph requires
a lot
of CPU
On Thu, Sep 12, 2013 at 03:44:53PM -0400, Jeff King wrote:
On Thu, Sep 12, 2013 at 12:35:32PM +0200, Josef Wolf wrote:
I'm not sure I understand correctly. I see that bitmaps can be used to
implement set operations. But how comes that walking the graph requires a
lot
of CPU? Isn't it O
case too
Last time I checked, cloning could not be resumed:
http://git.661346.n2.nabble.com/git-clone-and-unreliable-links-td7570652.html
If you're on a slow/unreliable link, you've lost.
:-( :-( :-(
--
Josef Wolf
j...@raven.inka.de
--
To unsubscribe from this list: send the line unsubscribe git
On Mi, Sep 11, 2013 at 10:14:54 -0700, Junio C Hamano wrote:
Josef Wolf j...@raven.inka.de writes:
On Di, Sep 10, 2013 at 10:51:02 -0700, Junio C Hamano wrote:
Consider this simple history with only a handful of commits (as
usual, time flows from left to right):
E
On Do, Sep 12, 2013 at 05:23:40 -0400, Jeff King wrote:
On Thu, Sep 12, 2013 at 09:42:41AM +0200, Josef Wolf wrote:
I think Junio is referring to the reachability bitmap work. We may know
that the other side has commit E (and therefore every object reachable
from it), but we do not walk
side would have told that it has heads X Y Z in addition,
and the sending side happens to have Y, then the sending side could in
addition remove any objects that can be reached from Y from the sending list.
--
Josef Wolf
j...@raven.inka.de
--
To unsubscribe from this list: send the line unsubscribe
/origin/master'
$
As we can see in this example, the big file is tranferred back to the first
repository, although it is already available there. This is very annoying if
you have a very slow connection.
Am I missing some important point here?
--
Josef Wolf
j...@raven.inka.de
--
To unsubscribe
No suggestions on this one?
On Wed, Oct 31, 2012 at 11:44:04AM +0100, Josef Wolf wrote:
I am somewhat unsure whether it would work this way. After all, there seems to
be an unbreakable rule with git: never rebase published branches.
Thus, once I have published my work to other people who
Hello,
I know, I should never rebase published branches. But...
I frequently work on different computers and would like to share my private
branches across them. When done and the feature is in a good shape, I'd like
to rebase to clean up history before I make it available to other people.
I
On Sat, Oct 27, 2012 at 08:45:45PM +0200, Enrico Weigelt wrote:
I'd suggest a 3 level branch hierachy (IOW: the lower level
is rebased ontop of the next higher level):
* #0: upstream branch
* #1: generic local maintenance branch
* #2: per-instance cutomization branches
Normal additions
22 matches
Mail list logo
