[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fossil-users
Subject:    Re: [fossil-users] diff before update
From:       Eduard <eduard.c.dumitrescu () gmail ! com>
Date:       2015-11-21 18:15:10
Message-ID: 5650B4AE.1090504 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hi Stephan,

On 11/21/2015 04:38 AM, Stephan Beal wrote:
> On Sat, Nov 21, 2015 at 12:24 AM, Eduard
> <eduard.c.dumitrescu@gmail.com <mailto:eduard.c.dumitrescu@gmail.com>>
> wrote:
>
>     The problem lies not with 'update'. The problem is that there's no
>     way to refer within other commands (specifically 'diff') to the
>     commit that 'update' (with no VERSION argument) would update to.
>
>
> Not even update knows which version it will pick until it is run.
> Therefore i don't foresee other commands being able to predict that.
> When update is run, it will sync (if enabled), the apply whatever the
> latest is (unless told otherwise, in which case it _does_ know in
> advance).
>
>  
>
>     In the above example, I would like there to be some alias
>     "update-target" that would resolve to
>     d83fc58dead2d03428a763b0890b8b5fbffb7957 (not actually suggesting
>     that as a name, there's probably a better name for it), so that I
>     could do "fossil diff --from current --to update-target".
>
>
> That update-target value is unknown at that point, and there's no way
> for diff to know it, in particular if autosync is on (which it
> normally is).
You make an excellent point/!/ (I forgot that most people do use
autosync.) To make everyone happy, I think it would be very useful
instead if there was a checkin alias "undo" that would refer to the
state of the local source tree if 'undo' were to be run. This way after
doing an 'update' (or even a 'merge'), one could run "diff --from undo
--to current" to see exactly what the last undo-able command changed. I
think it would also be pretty useful when doing more than 2-way merges.

Best,
Eduard

[Attachment #5 (text/html)]

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Stephan,<br>
    <br>
    <div class="moz-cite-prefix">On 11/21/2015 04:38 AM, Stephan Beal
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAKd4nAi_zDGGyY7tVRc0hwiAceb9rFKpy6bBU=7E4-A3=FXLpQ@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Sat, Nov 21, 2015 at 12:24 AM,
            Eduard <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:eduard.c.dumitrescu@gmail.com"
                target="_blank">eduard.c.dumitrescu@gmail.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote">
              <div><span class="">
                  <div>The problem lies not with 'update'. The problem
                    is that there's no way to refer within other
                    commands (specifically 'diff') to the commit that
                    'update' (with no VERSION argument) would update to.</div>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>Not even update knows which version it will pick until
              it is run. Therefore i don't foresee other commands being
              able to predict that. When update is run, it will sync (if
              enabled), the apply whatever the latest is (unless told
              otherwise, in which case it _does_ know in advance).</div>
            <div><br>
            </div>
            <div> </div>
            <blockquote class="gmail_quote">
              <div><span class="">
                  <div> In the above example, I would like there to be
                    some alias "update-target" that would resolve to <tt>
                      d83fc58dead2d03428a763b0890b8b5fbffb7957</tt> (not
                    actually suggesting that as a name, there's probably
                    a better name for it), so that I could do "fossil
                    diff --from current --to update-target".<br>
                  </div>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>That update-target value is unknown at that point, and
              there's no way for diff to know it, in particular if
              autosync is on (which it normally is).</div>
          </div>
        </div>
      </div>
    </blockquote>
    You make an excellent point<i>!</i> (I forgot that most people do
    use autosync.) To make everyone happy, I think it would be very
    useful instead if there was a checkin alias "undo" that would refer
    to the state of the local source tree if 'undo' were to be run. This
    way after doing an 'update' (or even a 'merge'), one could run "diff
    --from undo --to current" to see exactly what the last undo-able
    command changed. I think it would also be pretty useful when doing
    more than 2-way merges.<br>
    <br>
    Best,<br>
    Eduard<br>
  </body>
</html>


_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic